2.2.18/ext2: special file corruption?

2.2.18/ext2: special file corruption?

[Ulrich Windl]

Hi,

I had an interesting effect: Due to NVdriver I had a lot of system 
freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the 
message that one specific "Special (device/socket/fifo) inode .. has 
non-zero size. FIXED."

Interestingly I got the message for every reboot. So either the kernel 
corrupts the very same inode every time, or e2fsck does not really fix 
it, or the error simply doesn't exist. I think the kernel doesn't 
temporarily set the size to non-zero, so this seems strange.

Regards,
Ulrich

Re: 2.2.18/ext2: special file corruption?

[Walter Hofmann]

Ulrich Windl schrieb am Montag, den 26. Februar 2001:

> I had an interesting effect: Due to NVdriver I had a lot of system 
> freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the 
> message that one specific "Special (device/socket/fifo) inode .. has 
> non-zero size. FIXED."

I see them too on every fsck (after a crash). I'm using e2fsck 1.19 (but
not from SuSE. The rpm was built on snap.thunk.org, but I can't
remember where I got it from).

Walter

Re: 2.2.18/ext2: special file corruption?

[Andreas Dilger]

Ulrich Windl writes:
> I had an interesting effect: Due to NVdriver I had a lot of system 
> freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the 
> message that one specific "Special (device/socket/fifo) inode .. has 
> non-zero size. FIXED."
> 
> Interestingly I got the message for every reboot. So either the kernel 
> corrupts the very same inode every time, or e2fsck does not really fix 
> it, or the error simply doesn't exist. I think the kernel doesn't 
> temporarily set the size to non-zero, so this seems strange.

It is strange that it thinks ".." is a special inode.  Maybe e2fsck is
fixing the wrong problem (i.e. truncating the directory ".."), and it
later fixes the zero-length directory...  Could you try two things:

1) unmount the filesystem and run e2fsck on the broken filesystem 1 or 2
   times, to see if e2fsck is fixing the problem or not.

2) If it is fixing the problem you need to wait until the next time you have
   a system crash, start in single user mode.  If it is NOT fixing the problem
   you can do this right away.  Run "e2fsck -n" to see which inode number is
   corrupt (the -n option means e2fsck will not fix the filesystem), and then
   run "debugfs /dev/X", type "dump <inode_number>" and "ncheck inode_number"
   at the prompt (note you NEED the <> around the inode number for dump).
   Send the output.

Cheers, Andreas  
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: 2.2.18/ext2: special file corruption?

[Ulrich Windl]

On 26 Feb 2001, at 10:48, Andreas Dilger wrote:

> Ulrich Windl writes:
> > I had an interesting effect: Due to NVdriver I had a lot of system 
> > freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the 
> > message that one specific "Special (device/socket/fifo) inode .. has 
> > non-zero size. FIXED."
> > 
> > Interestingly I got the message for every reboot. So either the kernel 
> > corrupts the very same inode every time, or e2fsck does not really fix 
> > it, or the error simply doesn't exist. I think the kernel doesn't 
> > temporarily set the size to non-zero, so this seems strange.
> 
> It is strange that it thinks ".." is a special inode.  Maybe e2fsck is

Og course NOT: ``..'' is a meta syntax for ellipsis. I couldn't 
remember the inode number.

> fixing the wrong problem (i.e. truncating the directory ".."), and it
> later fixes the zero-length directory...  Could you try two things:
> 
> 1) unmount the filesystem and run e2fsck on the broken filesystem 1 or 2
>    times, to see if e2fsck is fixing the problem or not.

I did that, and actually it fixed the very same problem again. On a 
second run it was fixed. So either the "-a -t ext2" prevents the 
changes from being written back if the only problem was that special 
file, or there is some corruption undetected by fsck that in turn 
causes the kernel to corrupt the filesystem again and again, or I don't 
know. Here's the log from my tries:

elf:~ # fsck -f /dev/sda6
Parallelizing fsck version 1.19a (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Special (device/socket/fifo) inode 16600 has non-zero size.  Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sda6: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda6: 35542/86400 files (0.9% non-contiguous), 124965/172690 blocks
elf:~ # fsck -f /dev/sda6
Parallelizing fsck version 1.19a (13-Jul-2000)
e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda6: 35542/86400 files (0.9% non-contiguous), 124965/172690 blocks


> 
> 2) If it is fixing the problem you need to wait until the next time you have
>    a system crash, start in single user mode.  If it is NOT fixing the problem
>    you can do this right away.  Run "e2fsck -n" to see which inode number is
>    corrupt (the -n option means e2fsck will not fix the filesystem), and then
>    run "debugfs /dev/X", type "dump <inode_number>" and "ncheck inode_number"
>    at the prompt (note you NEED the <> around the inode number for dump).
>    Send the output.

I'll keep your message. Maybe you hear again from me.

Ulrich