On 14/10/15 20:14, Austin S Hemmelgarn wrote: > On 2015-10-14 14:53, Andy Lutomirski wrote: >> On Wed, Oct 14, 2015 at 11:49 AM, Christoph Hellwig <h...@infradead.org> >> wrote: >>> On Wed, Oct 14, 2015 at 11:38:13AM -0700, Andy Lutomirski wrote: >>>> One might argue that reflink is like copy + immediate dedupe. >>> >>> Not, it's not. It's all that and more, because it is an operation that >>> is atomic vs other writes to the file and it's an operation that either >>> clones the whole range or nothing. That's a very important difference. >> >> Fair enough. >> >> Would copy_file_range without the reflink option removed still be >> permitted to link blocks on supported filesystems (btrfs and maybe >> XFS)? > I would argue that it should have such functionality, but not do so by > default (maybe add some option to tell it to ask the FS to accelerate > the copy operation?).
Heh, so back to the REFLINK flag :) TBH given the overlap between "copy" and "reflink", I quite like the REFLINK flag as a general interface to reflink. thanks, Pádraig -- 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
