ZFS, SSD and encryption

[Karl Denninger]

On 7/22/2016 15:10, Eric A. Borisch wrote:
> On Fri, Jul 22, 2016 at 2:27 PM, Karl Denninger <karl at denninger.net> wrote:
>> On 7/22/2016 14:02, Eric A. Borisch wrote:
>>> On Friday, July 22, 2016, Karl Denninger <karl at denninger.net
>>> <mailto:karl at denninger.net>> wrote:
>>>
>>>
>>>     On 7/22/2016 07:48, Nikos Kastanas wrote:
>>>     > I have a Lenovo X220 laptop running FreeBSD 10.3-RELEASE with
>>>     ZFS and
>>>     > encryption on a plain HDD. I am considering buying a Samsung Pro
>>>     850 SSD to
>>>     > boost performance but I am not sure if TRIM and ZFS+Encryption
>>>     work well
>>>     > together. After some research online, I found *this page*
>>>     > <https://www.freebsd.org/doc/faq/all-about-zfs.html>which states the
>>>     > following:
>>>     >
>>>     > *Note: *
>>>     > ZFS TRIM may not work with all configurations, such as a ZFS
>>>     filesystem on
>>>     > a GELI-backed device.
>>>     >
>>>     > From what I can understand from the above note, I should not use the
>>>     > encryption option when installing FreeBSD with ZFS on an SSD.
>>>     TRIM will not
>>>     > work correctly and therefore the SSD performace will be impacted.
>>>     Meh.  Simply not true.
>>>
>>>
>>> It will not work on 10.3, but will work (as Karl demonstrates) on
>>> 11.x. Here's the commit to head enabling it:
>>>
>>> https://svnweb.freebsd.org/base?view=revision&revision=286444
>>>
>>> And here's what is in 10.3 (BIO_DELETE case returns EOPNOTSUPP):
>>>
>>> https://svnweb.freebsd.org/base/releng/10.3/sys/geom/eli/g_eli.c?revision=296373&view=markup#l319
>>>
>>>  -  Eric
>> Note that the system in question (from which the stats were pulled) was
>> on 10.2 for an extended period of time, with SSDs, and with
>> Geli-encrypted disks.  It was fine with no performance issues; whether
>> there is a problem with earlier releases has much to do with the disks
>> in question.
>>
>> In the case of the Intel 730s it works perfectly well even though TRIM
>> is not passed through in that case.
> Fair, but the original question was if "TRIM will not work correctly
> and therefore the SSD performace will be impacted" -- and the answer
> is that TRIM+GELI does not "work correctly" for 10.3, but it does for
> 11.x. This is only a performance (and not "is my data safe")
> statement.
>
> As you allude to, how much this impacts performance depends on the
> drive, partitioning / provisioning, and workload.
>
>  - Eric
Note the two-part original statement-of-claim.

1. TRIM will not work on GELI encrypted disks before 11.x (true)
2. Performance will be severely impacted due to #1 (not necessarily and,
with proper SSD selection, generally false)

This is far more dependent on the SSD in question than the workload. 
The machine from which those stats were pulled, now on 11.0-BETA1, was
on 10.2-STABLE for an extended period of time and has production loads
on it, including quite-heavy Postgresql DBMS use with a lot of table
write activity.

I never saw any evidence of performance degradation at all over that
time, and it has run with GELI-encrypted providers since I stuffed
AESNI-equipped processors in that particular machine (making FDE
reasonable in terms of CPU overhead) a few years back.

It just happens to be that one of the good choices in SSD selection from
a standpoint of not having performance go to hell correlates with your
data being safe as well.

I'm sure there are corner cases where #2 is true even with a
carefully-considered SSD selection but in the time I've been using the
Intel 730s I've not run into them.

The big benefit of TRIM is that by immediately notifying the drive of a
"freed" block it is able to choose how and when to consolidate and
pre-erase said blocks for later use.  Since NVRAM has to be erased in
fairly large blocks (frequently 4MB in size or even more) to be
re-written and the erase cycle is, relatively speaking, somewhat slow
being able to do this "in advance" of the demand to write a block can
bring quite-material performance improvements.  In addition, due to the
relatively large unit of erasure vis-a-vis the typical allocation size
on a file system there are a lot of other storage management
considerations that come into play; being able to do some or all of that
before the user demands a new block be written can be of great benefit
to performance.  But exactly how much this matters is dependent on many
things with one of the most-important being how well the microcode in
the drive is written in the first place......

I suspect the odds of running into performance trouble in the OP's
environment, that being a laptop-style computer for what are probably
"personal" (as opposed to "server") sort of workloads, if the OP uses
one of the Intel 730s as the SSD in question, approaches zero -- and of
course somewhere down the road the OP will probably roll forward to 11.x.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160722/9b07e403/attachment.bin>