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
