[gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC

[Duncan]

Daniel Campbell (zlg) posted on Wed, 29 Jul 2015 01:54:03 -0700 as
excerpted:

> On 07/28/2015 06:57 AM, William Hubbs wrote:
>>
>> I don't quite understand your question, but I'll give it a shot.
>>
>> With the new mount service, it will not matter whether the file systems
>> are local or on the network. It will be up to you to configure the
>> mounts for each file system to start in the right order and configure
>> their dependencies.
>>
>> I am not looking at deprecating fstab at this point; I'm not sure how I
>> would go about figuring out the locations of mount points without it
>> yet.
>>
> Okay, so OpenRC's filesystem management is more like an enhancement for
> standard /etc/fstab mounts?
>
> My apologies for the vague questions. Perhaps I should spend my next
> weekend off learning a bit more about how OpenRC handles mounting.

What openrc does now is the traditional three-stage (plus fscks where 
appropriate) mount.

1) root

The initial root mount is of course normally read-only, and handled 
either in the initr* or directly in the kernel.  What openrc does is 
remount it (after fsck if appropriate) using the options in fstab, 
normally including mounting it writable, altho some installations may 
keep root read-only by default, as I do here.

2) other local filesystems

Openrc's localmount service mounts these (after fsck if appropriate) 
using the standard mount -a, which basically mass-mounts everything (not 
marked noauto or on the remote filesystem types exclusion list) in 
fstab.  There's no explicit dependency handling other than processing 
remote filesystems separately, so the only ordering done is the sequence 
in which they appear in fstab, and that only because mount -a happens to 
do it that way.

So an admin must handle nested mountpoints, etc, manually, either by 
ensuring that the fstab listing sequence is correct if that's enough, or 
by setting them noauto in fstab, and either creating creating a custom 
service to mount them, or doing it entirely manually, issuing the mount 
commands at the CLI after boot, every time.

3) other remote/network filesystems

I have no personal experience with these, but presumably they work the 
same way as the local filesystem processing, no explicit dependency 
handling, only minimal implicit fstab-sequential dependency handling.


What williamh is proposing here is the addition of explicit dependency 
handling via mount service multiplexing, similar to the way openrc 
multiplexes its network interface services, thus making explicit 
dependencies on specific networks, and now filesystems, possible.


[While I'm now subsumed into systemd, I ran live-git openrc-9999 for many 
years, submitting and sometimes proposing patches for a significant 
number of bugs along the way.  My system setup is customized 
sufficiently, including multiple mounts, some of them nested, that I 
found ~arch openrc problematic as it was too granular, dropping a whole 
bunch of potentially troublesome changes at once, making troubleshooting 
difficult.  By running live-git openrc and religiously checking for 
updates and reviewing git log orig_head.., and git show-ing any commits 
that looked interesting, I could follow individual commit-level changes 
and see where things broke, giving me a head start in patching back to 
workability, when necessary.  Of course this helped catch some of those 
bugs before they ever made it into an ~arch release, let alone stable, so 
~arch users in particular were the beneficiaries. =:^)  Anyway, as a 
result of that, I tend to be rather familiar with openrc's workings, 
certainly at the service level, tho troubleshooting that did get me 
exploring the more esoteric functionality of some of the C-coded helper 
binaries from time to time, as well.  Now I'm subsumed into systemd, but 
as I said, by the time I switched, several other folks were evidently 
running openrc-9999 as well, filing bugs as necessary, and williamh was 
doing good things with openrc -- witness this thread -- so I think it was 
left in good hands. =:^)  And I still care about it as even if I'm 
subsumed, I think it's important that there continues to be *some* 
alternative to systemd, for much the same reason I make it a practice to 
note the location of fire extinguishers and exits when I'm traveling -- I 
want them available should worse come to worse and I have to use them!]

-- 
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