On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald <h.rei...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel