On Tue, Jul 11, 2017 at 01:44:23PM -0400, Phil Susi wrote: > On 7/11/2017 11:23 AM, Josh Triplett wrote: > >> There are two main methods for doing this, synchronously using the > >> "discard" mount option or asynchronously using fstrim [2]. Colin King did > >> some extensive benchmarking and found that on desktops and servers you > >> usually want a cron'ed fstrim [3]. > > > > This assumes that you can handle a disk-heavy job running via cron, > > rather than distributing the overhead over time. (That link mentions > > fstrim running for a long time even when run on a daily basis, let alone > > weekly.) Sometimes you want to maximize peak performance at the cost of > > extra overhead at specific times; sometimes you want consistent > > performance and no downward spikes. > > > > Ideally, I would suggest that we start enabling the "discard" option by > > default in d-i. That would also avoid spinning up a periodic cron job > > that runs regardless of actual need or disk activity. > > > > (One of the things I really wish we could do more easily is eliminate > > the numerous cron jobs that simply wake up, realize they have no work to > > do, and go back to sleep.) > > I assume that since this bug is still open in Debian, that Ubuntu > diverged here since we've had the fstrim cron job for a few years now. > I even came across a bug report not too long ago saying that it trashes > OCFS filesystems running on a SAN.
Yeah, I've had it trash a filesystem as well. That was a kernel bug that has since been fixed, so I didn't want to use that as an argument against, but I definitely know people who thought they'd mitigated that bug by disabling "discard" yet had their filesystems trashed because of the fstrim cron job.
