[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Inconsistent ext3fs after crash (2.2.19/0.0.7a)

On Sun, Jun 17, 2001 at 11:04:22AM +1000, Andrew Morton wrote:
> Files on /var tend to be opened in funny modes - lock files
> with O_SYNC or whatever.  Might be violating ordering in some manner.
> Could you please try a couple of things?
> 1: Use in-kernel recovery, not fsck recovery.  On RH systems
>    you can do this by creating the file /fastboot (I think) or
>    by adding `fastboot' to the kernel boot line.  Or you could
>    simply boot with `init=/bin/sh' and do the mount by hand.
>    Once the mount+recovery has completed, please unmount and run
>    fsck by hand.  If it comes up clean then it may be an
>    e2fsprogs problem.

I just waited until the fsck bombed out on startup - used the shell
to mount and unmount the fs and let the fsck -yf run immediatly.
The error was still there.

> 2: It would be very interesting to find out what file is causing
>    this.  Could you please run `ls -lRi /var > /tmp/foo' before
>    you crash, then afterwards, look up the offending inode
>    in /tmp/foo.  Once we know its filename, things may become
>    clearer.

The inode isnt in use before i pull out the pcmcia card it seems.
>From the inode number i guess its a pid file in /var/run beeing
created on pulling the pcmcia card. Probably an strace on the 
pcmcia cardmgr will help to see the last fs op. Ill try that
in a second:

Checking all file systems...
Parallelizing fsck version 1.21-WIP (01-Jun-2001)
/dev/hda7: recovering journal
/dev/hda7: clean, 39160/320640 files, 354596/640702 blocks
/dev/hda8: recovering journal
/dev/hda8: Clearing orphaned inode 96655 (uid=0, gid=0, mode=020600, size=0)
/dev/hda8: Already cleared block #0 (65025) found in orphaned inode 96655.
/dev/hda8 was not cleanly unmounted, check forced.
Deleted inode 96654 has zero dtime.  FIXED.
/dev/hda8: Inodes that were part of a corrupted orphan linked list found.

        (i.e., without -a or -p options)
/dev/hda9: recovering journal
/dev/hda9 has reached maximal mount count, check forced.
/dev/hda9: 11/128520 files (9.1% non-contiguous), 24448/514048 blocks
/dev/hda10: recovering journal
/dev/hda10: clean, 230066/1921984 files, 3434427/3840472 blocks

fsck failed.  Please repair manually.

CONTROL-D will exit from this shell and continue system startup.

Give root password for maintenance
(or type Control-D for normal startup):
(none):~# mount -n -o remount,rw /
(none):~# mount /usr
EXT3-fs: mounted filesystem with ordered data mode.
(none):~# setterm -dump
(none):~# grep 96655 inodes
(none):~# mount /var
EXT3-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT3-fs: mounted filesystem with ordered data mode.
(none):~# umount /var
(none):~# fsck -yf /dev/hda8
Parallelizing fsck version 1.21-WIP (01-Jun-2001)
e2fsck 1.21-WIP, 01-Jun-2001 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? yes

Inode 96655 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Inode bitmap differences:  -96654 -96655
Fix? yes

Free inodes count wrong for group #6 (15784, counted=15786).
Fix? yes

Free inodes count wrong (120378, counted=120380).
Fix? yes

/dev/hda8: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda8: 8388/128768 files (0.8% non-contiguous), 92484/257032 blocks
(none):~# setterm -dump

Florian Lohoff                  flo rfc822 org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]