Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fr, 20.12.19 14:10, Karel Zak (kzak@xxxxxxxxxx) wrote:

> On Fri, Dec 20, 2019 at 10:23:50AM +0100, Lennart Poettering wrote:
> > On Do, 19.12.19 16:42, Ben Cotton (bcotton@xxxxxxxxxx) wrote:
> >
> > > Over time, some users experience slow downs in certain flash storage
> > > devices. This might be alleviated by issuing a periodic fstrim command
> > > to the mounted file system. Devices and file systems that don't
> > > support fstrim are unaffected.
> >
> > So, if this is desirable, why doesn't the kernel do this on its own?
>
> When?

Under the same conditions as this new fedora feature? i.e. time?

> You can use "mount/swapon -o discard" to do it on-the-fly, but in some
> cases it's bad idea and it's better to keep it in user's hands.

Not saying it shouldn't be. i.e. could be a sysctl or so.

I am just wondering what in any way would be better if userspace
triggered this based on user configuration than when the kernel would
trigger this on its own?

> > Why do we need a userspace component that just gets an event from the
> > kernel and then tells the kernel to do something?
>
> It does not get any event from kernel. It starts in specified time
> operation which may be unwanted in another time.

Yeah, I meant the timer event as event from the kernel...
>
> > If this is generally
> > desirable, why is something as trivial as that not a kernel
> > functionality anyway?
>
> You want to ask at LKML ;-)

Nah, I don't. I am asking the folks behind the fedora feature, asking
about their implementation. It sounds weird having userspace
components whose only job is to issue one frickin' ioctl() every now
and then?

I mean, this reminds me of the venerable "update" daemon of
traditional UNIXes, whose only job was to call sync() every 30s or
so. We stopped doing that on Linux and instead let the kernel manage
flushing buffers on its own, on its own timing (taking some sysctl
tuning and tweaking into account). Why is the trimming much different
than this? i.e. doesn't the kernel know better when a good time to
trim is?

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?

To my knowledge ext4, xfs, btrfs all support "discard" natively. So
why do we need a userspace component to enqueue the same operation if
the file systems can do that anyway, at much better times?

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux