On Jul 3, 2014, at 12:43 PM, Uoti Urpala <uoti.urp...@pp1.inet.fi> wrote:
> On Thu, 2014-07-03 at 12:00 -0600, Chris Murphy wrote: >> What about a new fs_passno value of -1 that means "use default for this file >> system type", and systemd spawns fsck based on the recommendation of that >> file system's devs? > > How should the file system devs communicate their current > recommendation? If your answer is "they tell systemd developers, who set > that in systemd source, and then systemd is shipped to users", that > seems less than optimal. Why? It's static. I don't expect the recommendations to ever change, let alone often. > The "don't ship fsck.foo" or "symlink fsck.foo > to /bin/true" methods seem much better from the point of view that the > default is communicated with the filesystem tools. OK, then this sounds like the switch is the existence of fsck.<foo>, not the value of the root entry's fs_passno, in which case fs_passno for / is being deprecated by systemd. That's not going to be obvious to anyone. For many years now the fsck.<foo> is also a flag for a missing device. Hence upstream xfs-progs provides fsck.xfs, and Btrfs devs just added fsck.btrfs, for this purpose. So you're suggesting either a.) distros need to remove fsck.<foo> if they use systemd; or b.) upstream fs projects need to stop shipping fsck.<foo> and distros need to add them if they don't use systemd and still need an fsck to check for missing devices. What will actually happen in practice is fsck.<foo> will continue to exist, and will be a no op for those filesystems that don't do fsck. Which is what happens now. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
