Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as excerpted:
> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev <alo...@gentoo.org>
> wrote:
>
>> On 29 July 2015 at 23:20, William Hubbs <willi...@gentoo.org> wrote:
>>>
>>> so that there is a better idea out there of what I'm talking about,
>>> the OpenRC github repository now has a mount-service branch.
>>
>> But I still trying to figure out why do we need to keep fstab around.
>> It is pure legacy.
>>
>>
> On what planet is fstab pure legacy? Many utilities use it and expect it
> to exist. For example the ability to do "mount /foo" requires a properly
> configured fstab file (also mount -a).
>
> AFAIK even systemd needs a fstab file if you want to do anything that
> it can't autodetect by probing the system.
Based on systemd documentation and experience...
Systemd doesn't require an fstab file; its mount units are valid
replacements. But systemd _does_ still recommend using fstab at least
for normal admin-configured mounts, in preference to its own mount-unit
alternative. So systemd doesn't consider fstab legacy.
Systemd ships systemd-fstab-generator[1], which parses /etc/fstab and
places its dynamically created mount units in /run/systemd/generator.
It then uses these dynamically created *.mount units in combination with
those it ships[2] and any others created either dynamically by other
generators or by distros/other-packages or admins[3], instead of using
/etc/fstab entries directly.
But systemd's own docs still recommend using fstab in preference to its
own mount units, at least for mounts designed for admin control[4].
According to the systemd.mount (5) manpage, first paragraph in the FSTAB
section:
>>>>>
Mount units may either be configured via unit files, or via /etc/fstab
(see fstab(5) for details). Mounts listed in /etc/fstab will be converted
into native units dynamically at boot and when the configuration of the
system manager is reloaded. In general, configuring mount points through
/etc/fstab is the preferred approach. See systemd-fstab-generator(8) for
details about the conversion.
<<<<<
So while fstab isn't actually _required_ on a systemd-managed system as
its mount units offer the same functionality, its use is still
"preferred", and fstab is therefore not considered legacy.
And purely from a practical admin viewpoint, I can see see why...
>> There can be a migration script to generate /etc/conf.d/* configuration
>> once, but there is no need to keep it around.
>> The conf.d can contain everything that fstab contains.
>>
>> mount_mountpoint_\${NAME}=
>> mount_type_\${NAME}=
>> mount_fs_\${NAME}=
>> mount_opts_\${NAME}=
>> mount_dump_\${NAME}=
>> mount_pass_\${NAME}=
>>
>>
> That's a mighty verbose format, especially compared to fstab. I don't
> think we should force people to move away from fstab because we have a
> new and shiny service system.
... And that is _precisely_ _why_. =:^)
Systemd's mount units may offer the same functionality, but they're far
more verbose. Moreover the ratio is one fstab line per mount-unit file,
with mount-unit files potentially scattered in three different locations
in the file tree depending on their specific purpose and whether they're
running as shipped or created/customized by the sysadmin.
> Also if you are trying to get rid of "legacy" stuff, why on earth are
> you keeping dump and pass around? Both of those are certainly not needed
> if you are doing everything via services.
Good point. The dump and pass fields are actually optional in fstab now
days as well, with the defaults being 0 for both (don't dump and don't
fsck), if the field isn't present. And if we're getting rid of fstab,
anything using those fields will need code to handle some alternative
config format anyway (if it doesn't have it already), so might as well
simply drop the options from the mount config entirely, and let that
separate config handle it.
Meanwhile, if we're talking specific fstab replacement config format, no
need to reinvent the wheel, we might as well simply adopt systemd's
*.mount unit-file format as it covers all the bases, including
compatibility. =:^) The systemd mount-unit fstab field parallels,
according to the systemd.mount (5) manpage, Options section (quoting
abridged excerpts):
>>>>>
Mount files must include a [Mount] section. The options specific to the
[Mount] section of mount units are the following:
What=
[Mandatory: A]n absolute path of a device node, file or other resource to
mount.
Where=
[Mandatory: A]n absolute path of a directory of the mount point.
Type=
[Optional: A] string for the file system type.
Options=
[Optional: O]ptions to use when mounting. This takes a comma-separated
list of options.
<<<<<
That would be sufficient for an initial openrc implementation. Additional
optional options that an initial openrc implementation could ignore
include:
SloppyOptions=
Corresponds to mount's -s option, allowing unknown mount options.
Defaults to off.
DirectoryMode=
Mountpoints (and parents) are created if they don't exist. This sets
their (octal) mode. Default is 0755.
TimeoutSec=
Mount command timeout. If the mount command is still running after this
time, it is SIGTERMed. If it's still running after this time elapses
again, it is SIGKILLed. A unitless value is interpreted as seconds, or a
time value such as "5min 20s" can be given. 0 disables the timeout
entirely. Systemd sets the default at a higher config level, and openrc
would presumably do so as well.
Additionally, note that mount itself interprets both the nofail and noauto
options from the fstab options field or -o commandline option, but an
individualized mount service would have to parse them from the Options=
line above, avoiding invoking mount with noauto, and ignoring mount
failure with nofail.
And finally, systemd acts on a number of otherwise systemd specific
options out of the mount options field. Some of these are effectively
systemd specific, but there are two specific dependency related options
that it would be useful for openrc to act on as well, x-systemd.requires=,
and xsystemd.requires-mounts-for=. Both of these take an absolute path
and set systemd unit dependencies (Requires= and After= for requires,
RequiresMountsFor= for that one) one way or the other between this mount
unit and others.
It's worth noting that were openrc to act on these fstab options field
options as well, it would in doing so process fstab-configured
dependencies, and there'd be far less need to have separate
individualized service unit configuration, as dependencies could be
specified directly in fstab.
---
[1] systemd-fstab-generator: Installed on a normal systemd-managed system
as /usr/lib/systemd/system-generators/systemd-fstab-generator.
[2] Systemd shipped mount units: /usr/lib/systemd/system/var-run.mount,
for instance, which conditionally bind-mounts /var/run to /run, only if
/var/run already exists and isn't a symlink.
[3] Distro/package shipped mount units, as other distro/package shipped
units, will be installed as /usr/lib/systemd/system/*.mount, while admin-
created units should be created as /etc/systemd/system/*.mount.
[4] Mounts designed for admin control: as opposed to automated mounts
like the one mentioned in [2], that aren't intended for admin control,
with some of them part of the systemd API and thus with limited override
ability even via the usual /etc/systemd/system/ override location,
according to the manpage.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
