http://bugzilla.opensuse.org/show_bug.cgi?id=1043602 http://bugzilla.opensuse.org/show_bug.cgi?id=1043602#c6 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Stanislav Brabec <sbrabec@suse.com> --- Well, the interval was selected by the upstream after a long discussion. We have no plans to diverge util-linux from the upstream. If there are new facts about recent SSD discs and there is a statistics about SSD lifetime and performance with various fstrim setups, please open a new discussion in the util-linux-ng mailing list (and include people from the thread below to Cc). Running fstrim more often has unwanted side effects: - Running TRIM has performance impact. - TRIM itself can take long time to complete. - TRIM can shorten life of the SSD disc. Better heuristics would be fstrim based on the amount of data written. But something like that is not yet implemented and not easy to implement. Here is the reference to the discussion: http://www.spinics.net/lists/util-linux-ng/msg09133.html Especially this mail explains the interval: http://www.spinics.net/lists/util-linux-ng/msg09132.html From: "Theodore Ts'o" <tytso@xxxxxxx> Subject: Re: [PATCH] fstrim: add systemd units Date: Wed, 9 Apr 2014 14:39:54 -0400 For those SSD's that have a problem, "mount -o discard" is a disaster. Some turn into bricks, others will have a degraded flash cells, many will cause extremely degraded performance for other processes. What I usually tell people as far as who ask me for advice is that once a week is usually sufficient, especially for most desktop and server systems. If you are running an extreme workload which is doing a huge number of random writes, then sure, running fstrim more frequently, or even using "mount -o discard" might make a lot more sense --- especially if you are using PCIe attached flash. But in those cases, the system administrator might not want be willing to tolerate the random latencies in performance that might show up when fstrim is running (for pretty much all SATA and SAS attached SSD's out there, they don't yet support queued trim, so each trim command requires draining the NCQ queue, which is why sending trim commands, whether via "mount -o discard" or via fstrim will incur a performance penalty to whatever else might be trying to use the disk at the time). I'll note BTW that even using "fstrim" could potentially brick an especially inexpensive/trashy SSD, although the vendor for whose drive had been most commonly accused of promulgating those to the world is out of business (although there are probably plenty of those SSD's still in use in various community distros' audiences.) Cheers, - Ted -- You are receiving this mail because: You are on the CC list for the bug.