Date: Thu, 5 May 2016 08:39:30 -0600 From: Warner Losh <imp@bsdimp.com> To: fs@freebsd.org Subject: ZFS and SSD, trim caused stalling Message-ID: <5E710EA5-C9B0-4521-85F1-3FE87555B0AF@bsdimp.com>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXK1siAAoJEGwc0Sh9sBEAwBIQAOboHkv2tGcS02W6H3py4h7u oNIcVqR/dnf1WN35TKLQbYJFsfFXqGxFVkVl6yP7bjDj10XlyCj3i0dHiA9wi83u F+Y49TxmKUoYtSpmrB/qFLCRZg/RTBPbMAtMkbs/GhuSiGLT8yZ72ZZpDjufuBwl QcCiekZGIPaaH3CRtnysmWuGM7DS54uFdeUGBiiYxirAI3JXDYFZwN0yIPIZI6EK uiH3sO7JmocLg9FJooHwTQ1uIWLH6ujNQibzX4zzv1S/x3qsTVs1WiniFFCuN1MV PJy1cG8cH+WZSFggoDf7qDp4/XJHKPHuUaCDDDYmzpf569ID+emcLvKz0wEkjHyK +psl53DMXBAHPXg9witTqoe/tcxfc4hw3SOsVtVs3wF10+GhIfDxyBc1ynCvfTs5 XPJApJYXYM07XCvk68Vh+2j8SJRgojIsycRNSFK51Qv/tm0m0ept5k+FL/GE+/sc L4+T8W84sdgM0dwuK3fPua2G2gNHjEoknmlMbdsrXJquCXACx64aGpNDnwvF0ZZZ T3iPH2sZfrzK3p+Gx6vHJI34NBAUv6wqDn/Mc6z/UZJyYCHrBKKrAregxxI7KXJa /s7FBeKS3Ysz4SKvmemV03reqDI0ep+nXC1y/4cZoiCakL7TNSk9rjOKmupvQG+9 bNSabmhoVEFeK0Cej4nF =50Cy -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5E710EA5-C9B0-4521-85F1-3FE87555B0AF>