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. 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. >> 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. > 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
