Whamcloud - gitweb
b=2254
authorphil <phil>
Fri, 28 Nov 2003 06:54:24 +0000 (06:54 +0000)
committerphil <phil>
Fri, 28 Nov 2003 06:54:24 +0000 (06:54 +0000)
commitc5ffc397b78701ca9ea8f89a08c682ef74e04f4b
tree87c7bd64abc5d14971f37318e090db48e961e290
parenta5a022eb00f2d684b9d8f5deb51f7e2e46105c0f
b=2254
At truncate time, ext3 is zeroing indirect blocks and writing a
transaction to the journal.  At some point, perhaps when that
transaction commits, it gives the dirty buffer for that indirect block
to the buffer cache to write to disk.  Meanwhile, having marked that
block as unused, it reallocates it to us as a normal data block into
which IOR puts some data.

The obdfilter writes that block with brw_kiovec, which writes
immediately to the disk with no regard for what data might be in the
buffer cache.  Shortly thereafter, the buffer cache writes the block
of zeroes over top our valuable data.

The correct fix is to modify our special ext3 block allocation code to
look in the buffer cache for us, and discard any pending writes to the
newly-allocated blocks, much like the direct I/O code does.  As a
workaround, for kernels which do not yet have this change, I added
some code to the obdfilter to do this after the call to
ext3_map_inode_page returns.

This introduces kernel version 32, but doesn't force an upgrade.  I
updated the kernel patches for 2.4.18 and 2.4.20, but not 2.6.  I also:
 - tested the ext3_map_inode_page change on vanilla-2.4.20
 - tested the workaround change on chaos-2.4.18
 - compile-tested a version 32 chaos-2.4.18 kernel
lustre/kernel_patches/patches/ext3-extents-2.4.18-chaos.patch
lustre/kernel_patches/patches/ext3-map_inode_page_2.4.18.patch
lustre/kernel_patches/patches/ext3-o_direct-1.2.4.20-rh.patch
lustre/obdfilter/filter_io_24.c