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
