On Fri, Jan 20, 2012 at 15:20, Masatake YAMATO <yamato@xxxxxxxxxx> wrote: >> >> I'd like to add support for /etc/fstab.d to libmount. The library is >> currently used by mount, umount and mount.nfs. The goal is to use it >> on more places. >> >> The /etc/fstab.d directory has been requested by people who maintains >> large number of mountpoints etc. >> >> The directory is not replacement for /etc/fstab, it's additional place >> where you can describe your filesystems. >> >> The disadvantage is that the stuff in the directory will be invisible >> for some tools (udisks, systemd, ...), so I have very vocal >> disagreement from some people who don't want to see /etc/fstab.d at all. > > I'm working on systemd to support /etc/fstab.d. And we don't want to support that in systemd. It's an old glibc API, and /etc/fstab is ABI, not a service config file, which now can read more than one file. It's a very different problem. It an ABI change, not a config extension. Tools rightfully expect that they find all system mounts in that file, and not in some new split-up directory. In some cases, fstab is used to 'check if the device is not a system volume', and that will just break now, The gain of features from fstab.d/ vs. the amount of breakage it causes is not worth the trouble. And yes, there are systemd units, but we don't recommend anybody working with a general purpose system to mount system volumes with them. They are primarily used for virtual filessytems, which do not belong in fstab. In special purpose setups, like embedded, which do not care about POSIX-like APIs, the systemd units can replace fstab, but it's an entirely different story than breaking fstab expectations. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
