ZFS and SSD, trim caused stalling

[Warner Losh]

> What do you think? In some cases it’s clear that TRIM can do more harm than good.

I think it’s best we not overreact.

This particular case is cause by the nvd driver, not the Intel P3500 NVME drive. You need
a solution (3): Fix the driver.

Specifically, ZFS is pushing down a boatload of BIO_DELETE requests. In ata/da land, these
requests are queued up, then collapsed together as much as makes sense (or is possible).
This vastly helps performance (even with the extra sorting that I forced to be in there that I
need to fix before 11). The nvd driver needs to do the same thing.

I’ve implemented, but can’t find in my hg queues, code to do the deferral. After it gets the
first trim, it starts a 100ms timer and pushes all the trims together to the drive. This vastly
unclogs the drive and makes things snappier. I never committed this code upstream because
I never committed it to the Netflix repo. We found better ways in our application to avoid the
thing that was generating a boatload of TRIMs. I also never made them robust.

I’d be extremely hesitant to tossing away TRIMs. They are actually quite important for
the FTL in the drive’s firmware to proper manage the NAND wear. More free space always
reduces write amplification. It tends to go as 1 / freespace, so simply dropping them on
the floor should be done with great reluctance.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160505/b7cf911b/attachment.sig>