On Thu, Feb 6, 2014 at 4:51 PM, Karel Zak <k...@redhat.com> wrote: > On Sun, Dec 22, 2013 at 11:06:19AM +0100, Tom Gundersen wrote: >> 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... > > OK, I have improved fsck, so it does not print any error message if > fsck.<type> does not exist and the filesystem type is not in "really > wanted" set of the filesystems (the set was defined many years ago by > Ted and it's mostly about extN;-). > > # blkid -s TYPE /dev/sdb > /dev/sdb: TYPE="btrfs" > > # fsck /dev/sdb; echo $? > fsck from util-linux 2.24.184-663b-dirty > 0
Thanks! Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
