Boot time TRIM ?

[Allan Jude]

On 2020-08-25 20:35, Warner Losh wrote:
> On Tue, Aug 25, 2020, 2:02 PM Zaphod Beeblebrox <zbeeble at gmail.com> wrote:
> 
>> So, as I was looking at the performance of an NVME that I use for swap and
>> ZFS cache, I realized after reboot, that since ZFS cache doesn't survive
>> reboot and OBVIOUSLY swap doesn't, might it be best practice to issue a
>> TRIM on boot?
>>
> 
> No. Large TRIMs suck on too many devices. It might be helpful on a few
> devices. Some SSDs I've used would take minutes to trim...
> 
> Now... a trim on the whole device from userland before adding swap in RC...
>> might work.  AFAIK, we still don't have any structure to swap before it's
>> added.
> 
> 
> Not quite. We have to avoid trimming the first 8k to avoid stepping on boot
> blocks. The rest would be fair game.
> 
> I'm pretty sure this is not the right thing for ZFS cache and log
>> partitions, tho.
>>
> 
> Likely. ZFS should likely trim the useless areas.
> 
> Also, as a point of information, does ZFS issue TRIMs to the LOG after data
>> gets committed into a transaction?
>>
> 
> As it opens up holes, it will trim. FreeBSD ZFS and OpenZFS have different
> trim strategies, though, and I've not studied OpenZFS well enough. The
> FreeBSD implementation schedules TRIMs in batches...
> 
> I'm curious about this because for NVME that are a hybrid of different
>> storage --- commonly 10-20 percent faster MLC and 80 percent slower TLC (or
>> what-have-you) ... the TRIM usage can dramatically affect the performance.
>>
> 
> Yes, but the answer is it depends. The drive's firmware manages these
> things. Usually the mlc/slc bits of the drive are reserved for a pool to
> write quickly to. Then the drive rewrites this data to TLC when the free
> pool of blocks gets small enough.
> 
> I did some testing of this at work wrt swap, but we didn't swap enough for
> this to matter...
> 
> Warner
> 
> _______________________________________________
>> freebsd-fs at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 

Note, as of the import last night, the version of OpenZFS in FreeBSD now
supports a persistent L2ARC (cache) device. So on boot, it will
reprocess the list of buffers in the cache device and repopulate the ARC.

So for a cache device, there is not much point in worrying about TRIM
across reboots.

For the SLOG device, you basically overwrite the same blocks repeatedly,
and TRIM is likely a waste of time. You might be better off
under-provisioning instead. There really isn't much use for more than 16
or 32 GB of SLOG anyway.


-- 
Allan Jude

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20200825/7b6a8b21/attachment.sig>