On Tue, Apr 28, 2009 at 01:00:47PM -0400, Theodore Tso wrote: > On Tue, Apr 28, 2009 at 10:05:54PM +0530, Aneesh Kumar K.V wrote: > > On Tue, Apr 28, 2009 at 08:48:21AM -0400, Theodore Tso wrote: > > > On Tue, Apr 28, 2009 at 03:01:45PM +0530, Aneesh Kumar K.V wrote: > > > > > > > > Looking at the source again i guess setting just b_dev is not enough. > > > > unmap_underlying_metadata looks at the mapping block number, which we > > > > don't have in case on unwritten buffer_head. How about the below patch ? > > > > It involve vfs changes. But i guess it is correct with respect to the > > > > meaning of BH_New (Disk mapping was newly created by get_block). I guess > > > > BH_New implies BH_Mapped. > > > > > > Argh. So we have multiple problems going on here. One is the > > > original problem, namely that of a partial write into an preallocated > > > block can leave garbage behind in that unitialized block. > > > > > > The other problem seems to be in the case of a delayed allocation > > > write, where we return a buffer_head which is marked new, and this > > > causes block_prepare_write() to call unmap_underlying_metadata(dev, 0). > > > > Not just that. On block allocation we are not calling > > unmap_underlying_metadata(dev, blocknumber) for delayed allocated > > blocks. That would imply file corruption. > > I don't think I'm following you . If we write into block that was > delayed allocated. Are you saying we might get in trouble of the > delayed allocation block is mmap'ed in? We allocate blocks for delayed buffer during writepage. Now we need to make sure after getting the blocks we drop the old buffer_head mapping that we may have with this particular block attached to the block device. That is done by calling unmap_underlying_metadata. Now the current code doesn't call unmap_underlying_metadata for delayed allocated blocks. That would mean we can see corrupt files if old buffer_head mapping gets synced to disk AFTER we write the new buffer_head mapping. > > > The original reported problem is something really easy to reproduce. So > > i guess if we can have a ext4 local change that would fix the original > > problem that would be good. Considering that map_bh(bdev, 0) didn't > > create any issues till now, what we can do is to do a similar update > > for unwritten_buffer in ext4_da_block_write_prep. That's the v2 version > > of the patch with the below addition > > bh_result->b_blocknr = 0; > > OK, I can put togehter a patch to do this. Whatever we do, I think > we're going to need a *lot* of testing. I just sent -v3 version -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
