Date: Tue, 25 Aug 2020 22:07:11 -0400 From: Allan Jude <allanjude@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: Boot time TRIM ? Message-ID: <924f4c6e-f07e-99fb-ac4a-924efbd3dba3@freebsd.org> In-Reply-To: <CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w@mail.gmail.com> References: <CACpH0Me7dj%2BguVJu_%2BAUAYF60ZKtf8aR31bXFEYsU%2B93SunSJg@mail.gmail.com> <CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EPOA0FzXMmWRkDLUAROm0tliPUtjtIaVB Content-Type: multipart/mixed; boundary="cF4pKer6v2K4eY57eWC79dysUJyepnwtI"; protected-headers="v1" From: Allan Jude <allanjude@freebsd.org> To: freebsd-hackers@freebsd.org Message-ID: <924f4c6e-f07e-99fb-ac4a-924efbd3dba3@freebsd.org> Subject: Re: Boot time TRIM ? References: <CACpH0Me7dj+guVJu_+AUAYF60ZKtf8aR31bXFEYsU+93SunSJg@mail.gmail.com> <CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w@mail.gmail.com> In-Reply-To: <CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w@mail.gmail.com> --cF4pKer6v2K4eY57eWC79dysUJyepnwtI Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-08-25 20:35, Warner Losh wrote: > On Tue, Aug 25, 2020, 2:02 PM Zaphod Beeblebrox <zbeeble@gmail.com> wro= te: >=20 >> 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 survi= ve >> reboot and OBVIOUSLY swap doesn't, might it be best practice to issue = a >> TRIM on boot? >> >=20 > 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... >=20 > Now... a trim on the whole device from userland before adding swap in R= C... >> might work. AFAIK, we still don't have any structure to swap before i= t's >> added. >=20 >=20 > Not quite. We have to avoid trimming the first 8k to avoid stepping on = boot > blocks. The rest would be fair game. >=20 > I'm pretty sure this is not the right thing for ZFS cache and log >> partitions, tho. >> >=20 > Likely. ZFS should likely trim the useless areas. >=20 > Also, as a point of information, does ZFS issue TRIMs to the LOG after = data >> gets committed into a transaction? >> >=20 > As it opens up holes, it will trim. FreeBSD ZFS and OpenZFS have differ= ent > trim strategies, though, and I've not studied OpenZFS well enough. The > FreeBSD implementation schedules TRIMs in batches... >=20 > 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 TL= C (or >> what-have-you) ... the TRIM usage can dramatically affect the performa= nce. >> >=20 > 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 t= o > write quickly to. Then the drive rewrites this data to TLC when the fre= e > pool of blocks gets small enough. >=20 > I did some testing of this at work wrt swap, but we didn't swap enough = for > this to matter... >=20 > Warner >=20 > _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 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. --=20 Allan Jude --cF4pKer6v2K4eY57eWC79dysUJyepnwtI-- --EPOA0FzXMmWRkDLUAROm0tliPUtjtIaVB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJfRcPSAAoJEBmVNT4SmAt+OnUQAO2r6+8lsG4YwZhuESoT1GIO alTZSuaV9UevTAebKlMBl8LAqNkGeCJH49fiK3O9fpg3am4b8HPl/rYub1hlrKxh Jdror53sZ4Q1TX+851p5WpxaCl67E0XqrHVmFu2+26Tsq5+U4r8kFPYwY5SZwEIW tdqeIazdqh/+xUXQza5N5x1dl26tqfUh5qhg/Oy461yEfgmgsGOAgCdwpU5mEW7k J3MsMMLphwFkJTeSTtM7mzBc2NzpWn0Ly1vUDJfc+5X0uqrxgfZOxidJSBRVWgwE v+1WOQKHnodfJJT/r2Vf8A7bQGbKIK6QWxsajPzSHeds1S7OudQDX1kGw/pIXS4u fLx5O+EMA6fkA/8PzVD1FaD+CP18Y2FJZHDr6MY7fcTR8IaPEgJXVuiMQIAsXkHs NC5N+dWgyiD3e7eS/3uY7LkRt3loh/awr579F9yqlJJeZnIi4rt29sjmp35prtzr P6gNB1EwCuW58kyCw/dhFKbYNRewu4kkAwrm5zdzW6E7F5RbX8nrL692eyPTB8ZQ XfBg5BkTJWz3w3nDmZXkrtHgGKm5Xt4Zqv+j7nf0ICykHHkG3lpz6TpI1XeNV53m TvrXqaeu/MkUMgtJNmLEYsa0mnuGgioIEL/BHOopPhpDtv018hzVpFjr8KT3uEaH lEcIi4kmP9uSh7aR4kXn =hqPg -----END PGP SIGNATURE----- --EPOA0FzXMmWRkDLUAROm0tliPUtjtIaVB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?924f4c6e-f07e-99fb-ac4a-924efbd3dba3>