On 11/10/15 15:29, Christoph Hellwig wrote: > On Wed, Sep 30, 2015 at 01:26:53PM -0400, Anna Schumaker wrote: >> Reject copies that don't have the COPY_FR_REFLINK flag set. > > I think a reflink actually is a perfectly valid copy, and I don't buy > the duplicate arguments in earlier threads. We really need to think > more in terms of how this impacts a user and now how it's implemented > internally. How does a user notice it's a reflink? They don't as > implemented in btrfs and co. You're right that if the user doesn't notice, then there is no point exposing this. However I think the user does notice as there is a difference in the end state of the copy. I.E. generally if there is a different end state it would require an option, while if only a different copying mechanism it would not. I think the different end state of a reflink warrants an option for 3 reasons: - The user might want separate bits for resiliency. Now this is a weak argument due to possible deduplication in lower layers, but still valid is some setups. - The user might want to avoid CoW at a later time critical stage. - The user might want to avoid ENOSPC at a later critical stage. > Now on filesystem that don't always do > copy on write but might support reflinks (ocfs2, XFS in the future) > this becomes a bit more interesting - the difference he is that we > get an implicit fallocate when doing a real copy. But if that's > something we have actual requests for that's how we should specify > it rather than in terms of arcane implementation details. thanks, Pádraig. -- 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
