Re: ext2 FS corruption with 2.5.59.

[Andrew Morton <akpm@digeo.com>]

Oleg Drokin <green@namesys.com> wrote:
>
> Here is my version:
> 
> #!/bin/bash
> mke2fs /dev/hdb2
> mount /dev/hdb2 /mnt -t ext2
> cd /mnt
> /tests/fsstress -p10 -n 1000000 -d . &
> while /tests/fsx -c 1234 -N60309 testfile ; do rm -rf testfile*; done
> 
> > So I'm going to have to ask you to investigate further.  Does it happen on
> > other machines?  Other filesystems?  Older kernels?  That sort of thing.
> 
> Ok. I am able to reproduce that same thing on dual Pentium4 2.2GHz (HT enabled), 512M RAM.
> My testing reveals that 2.5.50, 2.5.52 and 2.5.53 do not have the problem.
> 2.5.54, 2.5.55, 2.5.59 have the problem.
> ext3 and reiserfs do not show this problem.
> Looking through 2.5.54, I found that changeset named "[PATCH] quota locking update" forwarded by you
> is the cause for the problem.
> (also by reviewing the changeset it became clear that in order to succesfully reproduce the
> problem one must have CONFIG_QUOTA to be disabled).
> This small patch below fixes the problem for me (just reverts back part of quota locking patch in fact).
> Also I think that taking BKL just to update some inode accounting stuff is kind of expensive,
> so certainly better solution must exist.

aaargggggghhh.  I noticed that when I was reviewing the patch, but promptly
forgot to check it more closely.

However, in reviewing it, I don't see exactly what's going on.  Because only
one process is accessing the stat information of the fsx inode anyway?

Yes, we need to rub out that i_bytes/i_blocks thing, replace it with an
atomically updated loff_t, etc.  But I'd like to understand what the exact
failure is first.  It _seems_ that stat has somehow seen a >4G value of
stat->size, but how can this happen???

I need to breathe life back into my P4 box, see if I can get it to happen
there.

Thanks.