On Tue, Oct 01, 2013 at 10:57:17AM +0200, Thomas Bächler wrote: > Am 01.10.2013 05:10, schrieb Lennart Poettering: > >>>> b) is tempting. Given fsck's improved internal ordering handling, is > >>>> there actually a usecase for ordering the fsck's? I can't think of any > >>>> off the top of my head... > >>> > >>> I struggle coming up with one. I mean, the only I could think of is "oh > >>> my, it always used to work that way, and it is documented that way, you > >>> break UNIX!", which isn't even a usecase, but just confusion. > > Those were exactly my thoughts. And since systemd never had a problem > with breaking tradition if it was a good idea, I thought we could simply > go ahead. > > Now, according to the fstab(5) manpage, the root fs should have passno 1 > and everything else should have passno 2. We could ensure the same > behaviour by having After=systemd-root-fsck.service in > systemd-fsck@.service. Serializing fscks like that makes only limited sense if you're doing it from the initrd. But if the fsck is run from the ro root, then yes, I guess you want to make sure that the fs that holds the fsck binaries is OK before continuing. I think that since you're defining completly new behaviour, it would be nice to implement this smartly, to avoid constraining parallelization artificially.
> If file system checks actually need to be manually ordered in a certain > manner (which I would consider an edge case), systemd provides a much > saner interface than a "pass number", namely Before= and After= ordering > on the fsck services using .d files. I'm not sure if it is saner. It is more verbose and complicated, and most people like to configure their fsck's through /etc/fstab, since it is more convinient than .d directories. Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... > On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. > The iSCSI client will import them as /dev/sda and /dev/sdb. That is a > case where, if you can, you would specify FsckPassNo because the > automatic detection likely stops at host boundaries. ...there might be use cases. Even if we drop support for ordering by fsck-no field in /etc/fstab, do we have a new way of configuring this through /etc/fstab? (Something like x-systemd.comment=After=systemd-fsck-var.service ?) Or is this really too much of an edge case? I don't think that the current fsck-no-related code is harmful in any way or a maintenance burden, so if it is dropped, it would be nice to cover all bases. > >> Things like that should probably just be automatically determined by > >> the machine, and not requiring a human to invent weird passes to do > >> the job. A boolean sounds fine to me. > > As Kay mentioned, /sbin/fsck is rather powerful these days. +1, as long as we don't break more complicated setups. > > OK, sounds good to me. Anyone wants to cook up a patch that removes > > FsckPassNo= from the core and makes sure the fstab generator only takes > > the "passno" field in fstab as boolean to enable fsck or not? > > My patch 1/3 already treats passno as a boolean - if passno > 0, we > enable fsck, otherwise we don't. (passno < 0 is treated the same as > passno == 0 by the current FsckPassNo code, so I kept that.) > > I can cook up a patch that removes FsckPassNo= - I omitted it here since > I was unsure whether people have it in unit files they wrote manually. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel