Re: [patch] FS (ext2) corruption generated by BLKFLSBUF/invalidate_buffers (2.2.x and 2.3.x)

Jason T Collins (jcollins@valinux.com)
Tue, 30 Nov 1999 14:55:01 -0800

On Thu, 25 Nov 1999, Andrea Arcangeli wrote:
> Jason and Samuel told me they could reliable reproduce fs corruption by
> writing to a filesystem while the ioctl(BLKFLSBUF) is running in parallel
> on the blockdevice where the fs is mounted.
>
> I understood what was going on: BLKFLSBUF is just an interface for
> invalidate_buffers and invalidate_buffers() trashes away _all_ the buffers
> beloging to such a blockdevice. _Dirty_ buffers included.
> ...
++> Please Jason could you confirm this my patch fixes the problem for your
> reproducible fs corruption? I only given it a try on a floppy and worked
> fine here.

Well, I have some good news, and I have some bad news. The good news is, your
patch does seem to fix something. But it doesn't fix everything. At least now
the filesystem corruption I am getting is limited to a single sort which seems
to be repeatable, rather than the obfuscated, incomprehensible sets of messages
I was getting.

This is running 2.2.14pre9 with Andrea's buffer-races-2.2.14pre7-2 patch
applied.

Remember (and for linux-kernelites not wholly familiar with the
discussion), my test case is two seperate processes running create file, delete
file, BLKFLSBUF on two files in the same directory.

After a few seconds I now get a string of error messages looking something like
this:

EXT2-fs warning (device sd(8,1)): ext2_free_blocks: bit already cleared for bloc
k 257682
EXT2-fs warning (device sd(8,1)): ext2_free_blocks: bit already cleared for bloc
k 257682
EXT2-fs warning (device sd(8,1)): ext2_free_blocks: bit already cleared for bloc
k 257682
EXT2-fs warning (device sd(8,1)): ext2_free_blocks: bit already cleared for bloc
k 257682
... etc, about 15 times or thereabouts.

This does not trip the error flag for ext2, so I must force fsck to clear the
trouble. fsck reports the following:

Inode 6496, i_blocks is 4294893888, should be 20512. FIXED.
Unattached inode 6496
Connect to /lost+found<y>? yes
Inode 6496 ref count is 2, should be 1. Fix<y>?

I've ran the test two times -- while the inode and the "should be" for i_blocks
are different between passes, the rest above remains the same.

It looks like we're hot on the trail though.

-- 
Jason T. Collins
Jr. Software Engineer

--
"Our minds are as insects on the windshield of life."  -- Operations
Support Motto


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/