Jan Kara wrote: >>> Imagine you have a file with blocks 1 and 3 allocated and block 2 is a >>> hole. You write blocks 1-3. Block 2 isn't allocated because of delalloc. >>> Now if inode is already in the current transaction's list, during commit >>> writes to blocks 1 and 3 will land on disk but write to block 2 will >>> happen only after pdflush finds it. >> And that should be fine with data=ordered mode right ?. Because since >> block 2 is not yet allocated we don't have associated meta-data. So >> even if we crash we have meta-data pointing to 1 and 3 and not 2. The >> problem is only when we write the meta-data pointing to block 2 and not >> block 2 itself ?. > Yes, it is correct. I may be just surprising (we didn't do things like > this in data=ordered mode before). Will it even be surprising? "fill-in-hole; crash;" today may give you the same thing, right? It's just that with delalloc it might be a bigger window in time for this to happen? -Eric -- 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
