On Dec 21, 2013, at 6:25 AM, Bastien Nocera <[email protected]> wrote: > > I wanted to integrate that in Fedora, through a systemd daily unit. I > was wondering whether this sort of integration (I'd intend to port the > fstrim-all code to C) should be in systemd itself, or whether it should > be a unit shipped separately (in the util-linux package maybe?).
For legacy SATA 3.0 spec drives and controllers, this is useful since their non-queued TRIM command complicates issuance with the file system discard mount option by default. For SATA spec 3.1 drives and controllers, this is a queued command, so between the file systems and block layer TRIM can be asynchronous with other commands. So I'd say if you can plan the obsolescence of scheduled fstrim, and ensure it only applies to SATA rev 3.0 links, and have some way of not running the command on schedule if the block device is busy (that is, the block device could have more than one file system so it's not sufficient to poll "a" file system, you'd need to see if the device itself is busy), then I think it's OK. Otherwise I'd leave it alone for manual end user configuration, the problem goes away in about 3 years anyway. Chris Murphy _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
