On Thu, Dec 3, 2009 at 9:58 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Thu, 3 Dec 2009, Erik Ableson wrote: >> >> Much depends on the contents of the files. Fixed size binary blobs that >> align nicely with 16/32/64k boundaries, or variable sized text files. > > Note that the default zfs block size is 128K and so that will therefore be > the default dedup block size. > > Most files are less than 128K and occupy a short tail block so concatenating > them will not usually enjoy the benefits of deduplication. > > It is not wise to riddle zfs with many special-purpose features since zfs > would then be encumbered by these many features, which tend to defeat future > improvements.
Well it could be done in a way such that it could be fs-agnostic (perhaps extending /bin/cat with a new flag such as -o outputfile, or detecting if stdout is a file vs tty, though corner cases might get tricky). If a particular fs supported such a feature, it could take advantage of it, but if it didn't, it could fall back to doing a read+append. Sort of like how mv figures out if the source & target are the same or different filesystems and acts accordingly. There are a few use cases I've encountered where having this would have been _very_ useful (usually when trying to get large crashdumps to Sun quickly). In general, it would allow one to manipulate very large files by breaking them up into smaller subsets while still having the end result be a single file. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
