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