On Fri, Oct 16, 2015 at 09:19:50AM -0400, Chris Mason wrote: > On Fri, Oct 16, 2015 at 05:25:44AM -0700, Christoph Hellwig wrote: > > On Fri, Oct 16, 2015 at 07:49:19AM -0400, Chris Mason wrote: > > > > Yes, that would be my preference. I'd also like to understand what > > > > exactly btrfs does in fallocate. > > > > > > For which part? The answer changes based on how many references there > > > are to a given fallocated region. > > > > Both cases. With btrfs allocating new block on every write how do you > > avoid that ENOSPC? Is there a unassigned block preallocation that's > > made persistent in some way? > > So: > > fallocate 1g -> foo > > reflink foo foo2 > > We've now implicitly doubled the size of the fallocate, but at reflink No, I don't think it implies that at all. the posix_fallocate() "future writes will succeed" guarantee only applies to foo, not to /copies/ such as foo2. At it's core, reflink is just an optimised file copy mechanism - the resultant copy should have the same behaviour as a file copied by read/write. Copies done by physically copying data do not duplicate fallocate() regions or guarantees from the source file to the destination file. > time btrfs doesn't account for the doubling. It's actually much > better in this case to just use a hole because neither foo or foo2 can > use the preallocated space until the 1g is fully unshared. Right - this implies unwritten extents should not be shared by reflink, instead either skipped (i.e. leave as a hole in foo2 as you suggest) or duplicated so that the next write to the region of foo2 will also succeed. I'd suggest that COPY_FALLOC (or whatever it'll get called) implies the latter behaviour, the default behaviour being the former... > When we're doing writes, it'll check the preallocated extents for extra > refs and force COW if any exist. So writes into a preallocated region > can enospc. This really seems like an btrfs interpretation/implementation issue, not a problem for reflink in general. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
