On 5/18/11 1:13 AM, Dave Chinner wrote: > It's entirely up to the filesystem how it treats blocks beyond EOF > during truncation. XFS frees them on truncate down, because it is > much safer to just truncate away everything beyond the new EOF than > to leave written extents beyond EOF as potential landmines. > > Indeed, that's why calling vmtruncate() as a bad fix. If you have: > > > NUUUUUUUUUUWWWWWWWWWOUUUUUUUUU > ....----+----------+--------+--------+ > A B C D > > Where A = new EOF (N) > A->B = unwritten (U) > B->C = written (W) > C = old EOF (O) > C->D = unwritten (U) > > Then just calling vmtruncate() will leave the blocks in the range > B->C as written blocks. Hence then doing an extending truncate back > out to D will expose stale data rather than zeros in the range > B->C.... Hm, running recent xfstests which includes fsx-with-fallocate should probably eventually catch that then. -Eric > Cheers, > > Dave. -- 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
