On Mon, Jul 27, 2015 at 6:26 PM, William Hubbs <willi...@gentoo.org> wrote: > > Some of the advantages of this approach are listed in the bug. Here are > a few more I can think of. >
As we discussed this is similar to the approach taken by systemd (though it parses fstab and creates service files dynamically). Some other advantages: 1. If a mount fails to load you can reload it using openrc, instead of mount -a (maybe you're using busybox/etc). 2. Services could depend on specific mounts, instead of mounts in general. 2a. If a depended mount fails, then the service fails. If you fix the issue, you can start the service and then trigger the mount automatically, etc. 3. If you want to programatically configure mounts you might be able to avoid fussing with fstab, and instead edit individual mount services. Systemd doesn't infer the mount name from the filename - it is stored inside. Likewise mount options are stored inside the file, so there is no need for fstab to exist. However, in practice most systemd mount units are created by the fstab generator, which dynamically creates/destroys them in /run as fstab changes. -- Rich
