On Sat, Dec 21, 2013 at 7:11 PM, Chris Murphy <li...@colorremedies.com> wrote: > > On Dec 21, 2013, at 6:44 AM, Kay Sievers <k...@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.
We don't actually check for btrfs, but simply skip any checking when /sbin/fsck.<fstype> does not exist. > 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. I'd argue that the systemd behavior of ignoring missing helpers should just be moved to fsck... -t _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
