On 02/28/10 15:58, valrh...@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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
