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. >From 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ádraig. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
