Messages in this thread | | | Date | Sat, 25 Jan 2003 15:13:01 -0800 | From | Andrew Morton <> | Subject | Re: ext2 FS corruption with 2.5.59. |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |