[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
From: Duncan <1i5t5.duncan () cox ! net>
Date: 2015-07-29 20:59:26
Message-ID: pan$c7153$9d1b866b$4f63fe10$74e8dbb7 () cox ! net
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic