Date: Fri, 8 Dec 2023 18:19:51 -0800 From: Mark Millard <marklmi@yahoo.com> To: olivier.freebsd@free.fr, freebsd-fs@freebsd.org Subject: Re: periodic trim for ufs2 ssds Message-ID: <CE945AE7-3C20-46BE-A7BE-A9FB2C00746A@yahoo.com> References: <CE945AE7-3C20-46BE-A7BE-A9FB2C00746A.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp_at_bsdimp.com> wrote on Date: Fri, 08 Dec 2023 14:13:07 UTC : > On Fri, Dec 8, 2023, 4:03 AM Olivier Certner <olivier.freebsd@free.fr> > wrote: > > > Hi, > > > > Did you consider trying 'fsck_ffs -B -E' on a toy system? From a glance > > at the code, these flags are not exclusive and should do what you expect. > > > > > I wouldn't expect that to work... > > If that works, then you also have the option of not turning on trim on the > > FS and instead periodically doing it at once, like you can do on ZFS. > > > > I'd go the other way. I'd turn trim on for UFS and monitor the system under > load. Newer drives I've evaluated have much better pathological behavior > than the drives of a few years ago... there's a lot of left over fud about > how it's always terrible... Also, possibly try use of: # sysctl -d vfs.ffs.dotrimcons vfs.ffs.dotrimcons: enable BIO_DELETE / TRIM consolidation possibly via loader.conf : # grep trim /boot/loader.conf vfs.ffs.dotrimcons=1 One can sometimes use: # gstat -spod for monitoring alternatives and get an idea if on-the-fly trim is rate limiting activity compared to not having it enabled. === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE945AE7-3C20-46BE-A7BE-A9FB2C00746A>