>2.3.24. I first suspected that the high memory patch did it, but it turned
>out that unmap_underlying_metadata() hack either introduced or triggered
>data/metadata corruption. (take a look at the buffer.c change) I cannot
unmap_underlying_metadata is obviously right to my eyes.
Better that you apply the inode bugfix posted by V. Ganesh today.
BTW, unmap_underlying_metadata can be optimized even more (note the
current version is just fine, this incremental one is only a nice
optimization):
--- 2.3.23/fs/buffer.c Tue Oct 26 21:30:50 1999
+++ /tmp/buffer.c Fri Oct 29 14:20:03 1999
@@ -1353,7 +1353,8 @@
err = inode->i_op->get_block(inode, block, bh, 1);
if (err)
goto out;
- unmap_underlying_metadata(bh);
+ if (buffer_new(bh))
+ unmap_underlying_metadata(bh);
}
set_bit(BH_Uptodate, &bh->b_state);
mark_buffer_dirty(bh,0);
@@ -1445,7 +1446,8 @@
err = inode->i_op->get_block(inode, block, bh, 1);
if (err)
goto out;
- unmap_underlying_metadata(bh);
+ if (buffer_new(bh))
+ unmap_underlying_metadata(bh);
}
if (!buffer_uptodate(bh) && (start_offset || (end_bytes && (i == end_block)))) {
@@ -1612,7 +1614,8 @@
err = inode->i_op->get_block(inode, block, bh, 1);
if (err)
goto out;
- unmap_underlying_metadata(bh);
+ if (buffer_new(bh))
+ unmap_underlying_metadata(bh);
}
if (!buffer_uptodate(bh) && (start_offset || (end_bytes && (i == end_block)))) {
Andrea
-
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/