Date: Tue, 26 Aug 2014 01:51:44 -0500 From: Scott Bennett <bennett@sdf.org> To: paul@kraus-haus.org Cc: freebsd-questions@freebsd.org Subject: Re: some ZFS questions Message-ID: <201408260651.s7Q6pijc023521@sdf.org> In-Reply-To: <5C83C4FD-571B-4557-8AD7-5578276D2ED5@kraus-haus.org> References: <201408070816.s778G9ug015988@sdf.org> <27DAA821-0303-4D51-ADA7-7780DB8FE85D@kraus-haus.org> <201408210837.s7L8bm01019230@sdf.org> <9207FB2C-5EDE-49A7-9B0E-7C9839250A7E@kraus-haus.org> <201408241001.s7OA19dZ004925@sdf.org> <5C83C4FD-571B-4557-8AD7-5578276D2ED5@kraus-haus.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Kraus <paul@kraus-haus.org> wrote:
> On Aug 24, 2014, at 6:01, Scott Bennett <bennett@sdf.org> wrote:
>
> > Paul Kraus <paul@kraus-haus.org> wrote:
>
> >> I tend to agree. I do not recall off the top of my head, but I *think* you can enable compression on a zvol, in which case you can get that added benefit on the encrypted data, if you have the CPU power to handle both the encryption and the compression at once without too big a performance penalty.
> >
> > That may be worth keeping in mind for the future, but my present
> > collection of both encrypted and unencrypted file systems that are
> > candidates to be moved into the care of ZFS are almost entirely compressed
> > already. Turning on compression for these would just add unnecessary CPU
> > overhead.
> > Hmm...how would zvol compression work? Would UFS2 data structures
> > still be meaningful? Would geli(8) or other g* utilities be able to find
> > the last sector(s) in order to create/read their label metadata?
>
> OK, I just checked and my zvol *does* have a compression property, so you can enable compression for zvols.
That's good to know in case I someday have other archival needs, but
in the current situation, wouldn't buy me much, if anything, for the CPU
costs, as noted above.
>
> In terms of how it would work, the same was a for a filesystem. Remember, ZFS compression happens to the blocks as they are written to the vdevs. In the case of a zvol, it looks like a raw device to the OS. The compression is transparent to the layer using the volume.
Hmm. I wonder whether zvols simulate actual devices enough to fool
gvinum(8) and its kernel module. Likewise for gpart(8)'s GPT scheme.
>
> On systems where I am CPU limited, I test each set of data I have to see if compression gets me anything. My home systems are MicroProliant N36L or N54L and with only 2 cores I am CPU limited :-) The larger systems I design and manage for clients are usually dual quad-core XEON, so I usually have tons of excess CPU, so I am much more liberal with my use of compression. I have found that Virtual Machine disk images (.vmdk files) tend to compress at better than 2:1, often better than 3:1.
At present, I'm stuck with a first-generation Core 2 Quad (Q6600 - 2.4
GHz), so encryption costs, checksums cost, compression costs, etc.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201408260651.s7Q6pijc023521>