Re: BTRFS file clone support for cp

["Pádraig Brady" <P@draigBrady.com>]

Joel Becker wrote:
> 	In some sense, using btrfs, nilfs2i, ocfs2 with refcount trees
> enabled, or any other CoW-ish filesystem is a tacit approval of the
> delayed ENOSPC.  The same can be said of "thin provisioning" LUNs.
> However, the other concerns are still valid.  A user invoking vanilla
> cp(1) expects two independent storage regions for the data.
> 	(Oh, and what about future support of de-duping in filesystems?
> :-)

I maintain an app to de-dupe at http://www.pixelbeat.org/fslint/
and I'll be adding reflink support as soon as it becomes available.
=46rom a filesystem point of view, one thing that would help speed
this up (and many other things like rsync etc.) would be to allow
one to associate say a sha-3 hash or whatever with the file, which
the filesystem would automatically clear when the file data changes.
So in general having a special set of extended attributes that
were auto cleared on file modification would be very useful for
lots of stuff.

cheers,
P=E1draig.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html