zfs discuss - Feb 2010 - ZFS compression and deduplication on root pool on SSD

I am running my root pool on a 60 GB SLC SSD (OCZ Agility EX). At present, my
rpool/ROOT has no compression, and no deduplication. I was wondering about
whether it would be a good idea, from a performance and data integrity
standpoint, to use one, the other, or both, on the root pool. My current problem
is that I''m starting to run out of space on the SSD, and based on a
send|receive I did to a backup server, I should be able to compress by about a
factor of 1.5x. If I enable both on the rpool filesystem, then clone the boot
environment, that should enable it on the new BE (which would be a child of
rpool/ROOT), right?

Also, I don''t have the numbers to prove this, but it seems to me that
the actual size of rpool/ROOT has grown substantially since I did a clean
install of build 129a (I''m now at build133). WIthout compression,
either, that was around 24 GB, but things seem to have accumulated by an extra
11 GB or so. Or am I imagining things? Is there a way to get rid of all of the
legacy stuff that''s in there? I already deleted the old snapshots and
boot environments that were taking up much space.

Thanks!
-- 
This message posted from opensolaris.org

On Sun, 28 Feb 2010, valrhona at gmail.com wrote:
> backup server, I should be able to compress by about a factor of 
> 1.5x. If I enable both on the rpool filesystem, then clone the boot 
> environment, that should enable it on the new BE (which would be a 
> child of rpool/ROOT), right?
If by ''clone'' you are talking about zfs''s clone, I
don''t think that
this will immediately save you any space since zfs clone is done by 
block references to existing blocks.  You would need to actually copy 
(or re-write) the files in order for them to be compressed.

Using lzjb compression sounds like a good idea.  I doubt that GRUB 
supports gzip compression so take care that you use a compression 
algorithm that GRUB understands or your system won''t boot.

Bob
--
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

On 02/28/10 15:58, valrhona at gmail.com wrote:
> Also, I don''t have the numbers to prove this, but it seems to me
 > that the actual size of rpool/ROOT has grown substantially since I
 > did a clean install of build 129a (I''m now at build133). WIthout
 > compression, either, that was around 24 GB, but things seem
 > to have accumulated by an extra 11 GB or so.

One common source for this is slowly accumulating files under
/var/pkg/download.

Clean out /var/pkg/download and delete all but the most recent boot 
environment to recover space (you need to do this to get the space back 
because the blocks are referenced by the snapshots used by each clone as 
its base version).

To avoid this in the future, set PKG_CACHEDIR in your environment to 
point at a filesystem which isn''t cloned by beadm -- something outside 
rpool/ROOT, for instance.

On several systems which have two pools (root & data) I''ve
relocated it
to the data pool - it doesn''t have to be part of the root pool.  This 
has significantly slimmed down my root filesystem on systems which are 
chasing the dev branch of opensolaris.

 > At present, my rpool/ROOT has no compression, and no deduplication. I 
 > was wondering about whether it would be a good idea, from a
 > performance and data integrity standpoint, to use one, the other, or
 > both, on the root pool.

I''ve used the combination of copies=2 and compression=yes on rpool/ROOT
for a while and have been happy with the result.

On one system I recently moved to an ssd root, I also turned on dedup 
and it seems to be doing just fine:

NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
r2      37G  14.7G  22.3G    39%  1.31x  ONLINE  -

(the relatively high dedup ratio is because I have one live upgrade BE 
with nevada build 130, and a beadm BE with opensolaris build 130, which 
is mostly the same)

						- Bill

On Sun, Feb 28, 2010 at 07:36:30PM -0800, Bill Sommerfeld
wrote:
> To avoid this in the future, set PKG_CACHEDIR in your environment to  
> point at a filesystem which isn''t cloned by beadm -- something
outside
> rpool/ROOT, for instance.
+1 - I''ve just used a dataset mounted at /var/pkg/download,
don''t know
when this knbob appeared but i''only heard about it recently and not
yet bothered to rearrange stuff accordingly. 
> On one system I recently moved to an ssd root, I also turned on dedup  
> and it seems to be doing just fine:
I have had compress=on,dedup=on on several rpools for some time,
including a little netbook with a 7.5G slow-as ssd.

--
Dan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/119abb40/attachment.bin>

One of the great privileges of using OpenSolaris is the helpfulness and deep
knowledge of the community. Thanks for the suggestions.

I cleared out /var/pkg/downloads, and got back a couple of gigabytes.
I''ve enabled compress and dedup.

Is there a simple set of commands that I could send that filesystem somewhere,
bring it back on to the now dedup/compress-enabled boot, and then update BE to
get it to work? I''m assuming I could this with send/receive, but are
there some options that I need to specify? Or is there a way to force beadm to
copy the files over to a new filesystem, so that it ends up being deduped?

This SSD Is only for my rpool. I''ve got a mirror of SATA drives to
handle the data separately.

Also, assuming I recover most of the space, is there anything I can do to
clean-up the SLC SSD, like TRIM, but compatible with ZFS?
-- 
This message posted from opensolaris.org