jim owens wrote: > Jamie, > > Joel Becker wrote: > > "Shares the data extents of the source file". > > so with that clarification, do you now agree with this > > > 1) is only for filesystems with COW operation, > > if the fs does not support COW it returns ENOSYS. > > being a requirement so the user can trust that calling > reflink() uses minimal space (inode/extentmap) and only Yes I do, if > a change to the file will trigger a data copy. "file" means the data, not the permissions and timestamps :-) Otherwise there's still a user trust issue, since many applications come to mind who would like to chmod/chown/futimes immediately after making the reflink, and they need to trust that the result uses minimal space. I realise now in the OCFS2/BTRFS cases this isn't an issue since changing the data only unshares a small region of the data anyway. But that's quite a difficult thing to ask of any filesystem which implements reflink(), whereas saying "attribute changes do not trigger COW" (well maybe chown/chgrp do) is reasonable for any filesystems which can implement reflink(). -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
