Date: Tue, 25 Aug 2020 18:35:34 -0600 From: Warner Losh <imp@bsdimp.com> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: freebsd-fs <freebsd-fs@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Boot time TRIM ? Message-ID: <CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w@mail.gmail.com> In-Reply-To: <CACpH0Me7dj%2BguVJu_%2BAUAYF60ZKtf8aR31bXFEYsU%2B93SunSJg@mail.gmail.com> References: <CACpH0Me7dj%2BguVJu_%2BAUAYF60ZKtf8aR31bXFEYsU%2B93SunSJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 25, 2020, 2:02 PM Zaphod Beeblebrox <zbeeble@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo_-E-rXn8OYYraZkbgKBeevvR=bEjX7atwOj6Jru=h8w>