[systemd-devel] fstrim "cron" job

[Kay Sievers]

On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
>
> Am 21.12.2013 14:44, schrieb Kay Sievers:
>> Trimming should be the job of the filesystem, not for a nasty cron
>> job. We do not want to support legacy filesystems with upstream
>> shipped systemd units.
>
> doing it permanently on the fs-layer degrades all time performance
> doing it in a cron job regulary does not affect performance that way

No. Modern filesystems are like kernel services not silent and dumb
dong nothing in the background. They can do whatever they need to do
in whatever manner, and they can do it right.

Userspace can _never_ be better than a well-engineered modern file
systems while it is running. Maybe if you can unmount it and do it at
that time, that could be simpler and more efficient, but not while it
is running. Running cron jobs for normal filesystem maintenance is
just wrong at too many levels.

>> Readahead is pointless and wrong enough already to ship and enable in
>> systemd; using slows down bootup on all of my machines
>
> yes and no
>
> the question is not only hwo long the boot process itself takes
> how long does it take until you KDE/GNOME session is fully loaded
>
> there are always a few seconds between boot and enter username / pwd
> in this time window readahead already loads things from disk which
> are need due login - the summary of both is the interesting number

I have auto-login and using read-ahead was just slower. Maybe the new
block multi-queue stuff changes the picture; but in general I'm
convinced that read-ahead is a tool from the past on current modern
systems/SSDs, it should no longer be enabled by default.

Kay