Hi all, I''m running out of space on my OpenSolaris file server and can''t afford to buy any new storage for a short while. Seeing at the machine has a dual core CPU at 2.2GHz and 4GB ram, I was thinking compression might be the way to go... I''ve read a small amount about compression, enough to find that it''ll effect performance (not a problem for me) and that once you enable compression it only effects new files written to the file system. Is this still true of b134? And if it is, how can I compress all of the current data on the file system? Do I have to move it off then back on? Thanks for any advice, Ben -- This message posted from opensolaris.org
On 25 Jul 2010, at 14:12, Ben <ben.lavery at gmail.com> wrote:> I''ve read a small amount about compression, enough to find that it''ll effect performance (not a problem for me) and that once you enable compression it only effects new files written to the file system.Yes, that''s true. Compression on defaults to lzjb which is fast; but gzip-9 can be twice as good. (I''ve just done some tests on the MacZFS port on my blog for more info)> Is this still true of b134? And if it is, how can I compress all of the current data on the file system? Do I have to move it off then back on?Any changes to the filesystem only take effect on newly written/updated files. You could do a cp to force a rewrite but in the interim would take space for the old and new copies; furthermore, if you have snapshots, then even removing the old (uncompressed) files won''t get the space back. If you destroy all snapshots, then do a cp/rm on a file by file basis you may be able to do an in-place compression. Alex
Thanks Alex, I''ve set compression on and have transferred data from the OpenSolaris machine to my Mac, deleted any snapshots and am now transferring them back. It seems to be working, but there''s lots to transfer! I didn''t know that MacZFS was still going, it''s great to hear that people are still working on it. I may have to pluck up the courage to put it on my Mac Pro if I do a rebuild anytime soon. Thanks again, Ben -- This message posted from opensolaris.org
On 2010-Jul-25 21:12:08 +0800, Ben <ben.lavery at gmail.com> wrote:>I''ve read a small amount about compression, enough to find that it''ll effect performance (not a problem for me) and that once you enable compression it only effects new files written to the file system. >Is this still true of b134? And if it is, how can I compress all of the current data on the file system? Do I have to move it off then back on?Yes, changing things like compression, dedup etc only affect data written after the change. The only way to re-compress everything is to copy it off and back on again. Good news: There is an easy way to do this and preserve (whilst compressing) all your snapshots. All you need to do is set compression=gzip (or whatever you want) and then do a send/recv of that filesystem. The destination fileset will be completely created according to the source fileset parameters at the time of the send. If you have sufficient free space, you can even do a send|recv on the same system - but if the original fileset was mounted that this will result in the new fileset being mounted over the top of it, so you shouldn''t do this on an active system. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100726/9d30ca8f/attachment.bin>
>> I''ve read a small amount about compression, enough to find that it''ll effect performance (not a problem for me) and that once you enable compression it only effects new files written to the file system. > > Yes, that''s true. Compression on defaults to lzjb which is fast; but gzip-9 can be twice as good. (I''ve just done some tests on the MacZFS port on my blog for more info)Here''s a good blog comparing some ZFS compression modes in the context of the Sun Storage 7000: http://blogs.sun.com/dap/entry/zfs_compression Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl