On Fri, Oct 02, 2015 at 04:35:53PM +0800, Qu Wenruo wrote: > Hi Dave, I updated the patch and moved it to btrfs. > > But I still has some question about the fallocate behavior. > > Just as the new btrfs test case, I changed the fallocate range, not > to cover the last part, to make the problem more obvious: > > Btrfs will truncate beyond EOF even that's *not covered* by the > fallocate range. > > It's OK for a fs to modify the extent layout during fallocate, but > is it OK to modify extent layout completely *out* of the fallocate > range?
It's beyond EOF, so the filesystem can make whatever changes to allocated blocks in that space whenever it likes because userspace cannot access it. In XFS, we don't remove unwritten extents beyond EOF if they were placed there by fallocate except via explicit truncate() or fallocate() operations (e.g. hole punch) from userspace that manipulate that extent range beyond EOF. What other filesytems do with blocks beyond EOF in any given operation is up to the filesystem, really. If btrfs wants to truncate away all extents beyond EOF when punching a hole that spans EOF, then you can do that. It might not be what the user expects, but blocks beyond EOF don't fall under posix_fallocate() because it explicitly states: "If the size of the file is less than offset+len, then the file is increased to this size; otherwise the file size is left unchanged." which means it can't allocate blocks beyond EOF.... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
