On Sun, Dec 22, 2013 at 11:06:19AM +0100, Tom Gundersen wrote:
> On Sat, Dec 21, 2013 at 7:11 PM, Chris Murphy <[email protected]> wrote:
> >
> > On Dec 21, 2013, at 6:44 AM, Kay Sievers <[email protected]> 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
Karel
--
Karel Zak <[email protected]>
http://karelzak.blogspot.com
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
