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

Re: FS corruption; HTREE-related?



Hi,

On Mon, Oct 07, 2002 at 05:07:20AM +0000, JP Howard wrote:
> Over the last two days we've been seeing a fair bit of this:
 
> ----
> # ls -laR > /dev/null
> ...
> ls: ./server2/b/user/bxyz/392.: Input/output error
> ----

What else is in the kernel logs?  That is a sign of a disk failure,
usually (though it doesn't appear to be in this case.)

> This is with the latest htree patches applied to 2.4.19, and latest
> e2fsprogs-test, on a dual AMD system, with 5x73GB SCSI drives on a
> MegaRAID controller. We're using the gcc 2.96 that comes with RH7.3.
> 
> esfsck shows "Inodes that were part of a corrupted orphan linked list
> found."

That can be a harmless side-effect of an older version of e2fsck.  If
e2fsck finds a partial truncate which needs to be completed, it used
to leave the dtime field of the inode intact rather than clearing it.
That shows up on the *next* forced fsck as the error you saw.  If you
used an older fsck on the last reboot, that would explain this
message.

> [root server5 data]# ls -laR > /dev/null
> ls: ./server2/b/user/bxyz/392.: Input/output error
 
> debugfs:  stat 392.
> Inode: 14992585   Type: regular    Mode:  0600   Flags: 0x0   Generation:
> 2449155561
> User:   504   Group:   505   Size: 0
> File ACL: 0    Directory ACL: 0
> Links: 0   Blockcount: 0
> Fragment:  Address: 0    Number: 0    Size: 0
> dtime: 0x3da0be92 -- Sun Oct  6 17:52:02 2002

Empty file, dtime set, links==0 --- it's definitely a deleted file.

> debugfs:  testi 392.
> Inode 14992585 is not in use

Deleted file confirmed.

> Any ideas on what's causing this? e2fsck causes the problem files to be
> removed. For now we've disabled directory indexing--if the problem
> continues after doing this, I'll update the list with the details.

Thanks, we need that to work out where the problem might be.

> BTW, now that I've disabled directory indexing, will folders with the
> relevent flag already set still use hashed indexes?

How did you disable it?  If you switched to an older, non-htree
kernel, then any directories you modify will get their dir index bit
cleared, and you'll lose the index on those dirs.  But directories you
don't modify retain the index and if you reboot into an htree kernel,
you can use those indexes again.

If you just cleared the dir index bit with htree, then the htree data
structures will be completely ignored, but you can recreate them with
fsck.

--Stephen





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