[systemd-devel] fstrim "cron" job

[Chris Murphy]

On Dec 21, 2013, at 6:44 AM, Kay Sievers <kay at vrfy.org> wrote:

> 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.
> 
> Also, util-linux must not ship such policy, it's a collection of
> tools, not a system policy carry-out.

Well it's the job of the file system, the device mapper, the block layer, the ATA driver, the controller and then the drive. And at the bottom of this stack, the drive specification, is flawed. We're not going to see the file systems doing this in ideal fashion, none of them set discard by default, until everything below is properly enabling asynchronous queued TRIM.

So the question is whether it makes sense to design a work around for what amount to legacy devices (even though they are still being bought and sold today), or entirely ignore this (automatic) optimization for the life of the devices and leave it up to the user to set such things.

> We need to support fsck because it's needed for integrity and using
> filesystems that need, but running trim is just an optimization. We do
> not want the bugs for these filesystems triggered by the systemd
> package.

It seems systemd now parses fstab and can second guess its contents, e.g. it will ignore fs_passno for Btrfs, so even if it's a non-zero value, systemd doesn't cause fsck to go looking for an fsck.btrfs.

But it does for xfs, which likewise doesn't need fsck at all. I don't know if these optimizations really belong in systemd or rather in a smarter fsck to keep a list of file systems that do and don't need fsck performed on them prior to remount as rw. Arguably Btrfs and XFS can be mounted rw from the get go. And for ext3/ext4 fsck is still done presumably because they could have journaling disabled.


Chris Murphy