pedantic comment below... dave johnson wrote: > "Richard Elling" <[EMAIL PROTECTED]> wrote: >> Dave Johnson wrote: >>> "roland" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>> > >>> > there is also no filesystem based approach in >>> compressing/decompressing a whole filesystem. >>> one could kludge this by setting the compression parameters desired on >>> the tree then using a perl script to walk the tree, copying each file to >>> a tmp file, renaming the original to an arbitrary name, renaming the tmp >>> to the name of the original, then updating the new file with the original >>> file's metadata, do a checksum sanity check, then delete the uncompressed >>> original. >> This solution has been proposed several times on this forum. >> It is simpler to use an archiving or copying tool (tar, cpio, pax, >> star, cp, rsync, rdist, install, zfs send/receive et.al.) to copy >> the tree once, then rename the top directory. It makes no sense to >> me to write a copying tool in perl or shell. KISS :-) > > That's not compresing an existing file tree, that's creating a compressed > copy, which isn't the problem asked. How do you do that if your tree is > full (which is probably the #1 anyone would want to compress an existin > tree) ?
IMHO that is a management problem, not a technology problem. > You must be lucking enough to use BLISS (buying luns increases storage > st...) :) Prior planning prevents piss-poor performance. Really. ;-) -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
