I was heavily affected by this not running by default. I was almost convinced my hardware was broken, since there is no warning while having it not enabled, the last journalctl entries when the system freezes during a copy operation is from libinput that the mouse events can't be handled due to some latency. fstrim saved the day. My first thoughts after reading into this thread was if this could not be done automatically at storage device idle time instead of at time[date] but this has already been mentioned. Thank you Chris for this Change proposal. On Fri, Dec 20, 2019 at 8:57 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Fri, Dec 20, 2019 at 10:22 AM Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > > > On Fr, 20.12.19 18:11, Louis Lagendijk (louis@xxxxxxxxxx) wrote: > > > > > On Fri, 2019-12-20 at 17:46 +0100, Lennart Poettering wrote: > > > > > > > > Or let me ask this differently: the "discard" mount option of various > > > > kernel file systems, what does it differently than what this new > > > > fedora feature is supposed to do? > > > > > > > fstrim does the discard once a week (or whenever it it triggered), > > > discard as a mount option does trigger discard when a block is freed. > > > Depending on the drive it may actually slow down IO as the SSD will > > > need more time to finish the IO. Doing an fstrim leaves the processing > > > to the SDD. That was the argument years ago. I don't know if this is > > > > Hmm? if the if the fs enqeues the trimming or userspace does, it's > > always the SSD that executes it... > > Sure. And devices, nor their standards, provide sufficient information > indicating their preference for such hints. Nor do devices indicate > the ensuing firmware behavior, as a result of getting those hints. And > the unsophisticated state of the kernel's facilities reflects the > unsophisticated state of devices and standards. > > > > still true for modern SSD's. For older SSDs fstrim would stil be the > > > safer option. And automatic trimming is long overdue in my opinion. > > > > So if trimming is slow, that's still no reason to let userspace pick a > > time for it. Sounds like the kernel fs should have discard=lazy or > > discard=5min or so. Which would enqueue a trim run automatically after > > the last IO after some delay. > > > > Still not grokking why to do this in userspace. > > The rudimentary userspace method proposed, exists today. The weekly > issuance makes it unlikely users will notice the effects, in the case > they have a device+workload that would exhibit a delay while the > firmware acts on the command, while still reaping the benefit. > > Whereas the existing kernel facility is inadequate, and a more > sophisticated facility doesn't exist, and isn't likely to exist in the > near future. The problem isn't well enough understood, nor is the > solution - and I direct that at the industry, not just kernel > developers. Should this change, and the kernel gets these facilities, > it's trivial to back out the userspace change. > > It is really a case of accepting an existing one size fits all > solution. Rejecting the proposal probably does hurt a tiny number of > users, but it does so disproportionately. > > -- > Chris Murphy > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
