From df9276719d4e27cb8ccaeb76f5e61ce14f43355e Mon Sep 17 00:00:00 2001 From: phil Date: Fri, 28 Nov 2003 06:54:22 +0000 Subject: [PATCH] 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/lustre_version.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lustre/kernel_patches/patches/lustre_version.patch b/lustre/kernel_patches/patches/lustre_version.patch index 7d63999..86f514b 100644 --- a/lustre/kernel_patches/patches/lustre_version.patch +++ b/lustre/kernel_patches/patches/lustre_version.patch @@ -7,6 +7,6 @@ --- /dev/null Fri Aug 30 17:31:37 2002 +++ linux-2.4.18-18.8.0-l12-braam/include/linux/lustre_version.h Thu Feb 13 07:58:33 2003 @@ -0,0 +1 @@ -+#define LUSTRE_KERNEL_VERSION 31 ++#define LUSTRE_KERNEL_VERSION 32 _ -- 1.8.3.1