Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All, here is my update on this issue. Please look at the branches called mount-fail and remove-netdev on the OpenRC repository. I would like to commit these before the next release if there are no major issues. The first makes it possible for netmount and localmount to fail if some of the filesystems they mount do not mount (depending on how fstab is set up) and the second removes the util-linux specific -O [no]_netdev from the mount calls since these are both incompatible with busybox. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All, This is my previous post, added on the right thread this time. as I have always said, my views can evolve with civil discussion, and there has been some good feedback on this. I also got a suggestion for handling network file systems that would mean we wouldn't have to keep track of the specific clients needed to mount network file systems; we could let the distros tell us what the network file system types are and which services should be started to support them. Look at the new-netmount branch for that. Basically it would be a series of files in a directory which would have the name of a filesystem type as their file name, then inside each file, the name of the service that supports them. The point of debate I suppose is the dependency type that should be used for these. On the branch it is use, which requires you to add the appropriate service to the runlevel netmount is in, but some want it to be want once it is implemented. Also, I want to talk more about netmount and localmount failing. If netmount and localmount are set up to fail if one of the file systems they mount fails (which is what other init systems out there do), the sys admin can control whether the mount -a command cares about the status of specific file systems by adding nofail to the mount options in fstab. By default it would care, but if you add nofail to the mount options, you would affectively tell mount -a to not be concerned about whether the mount succeeds or not. Thoughts? William > signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Wed, Aug 5, 2015 at 8:09 PM, James Cloos wrote: >> "WH" == William Hubbs writes: > WH> What do folks think of these changes? > > For local filesystems, mount -a is exactly right and should remain. At > least for those of us who prefer only ever halving to edit fstab(5). > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 +1 Having yet another place to have to edit to mount local disks is just not a viable option. -- G.Wolfe Woodbury redwo...@gmail.com
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
> "WH" == William Hubbs writes:
WH> The other change I want to make, considering that the mount.* scripts
WH> will actually do the work of mounting the file systems, is to turn
WH> localmount and netmount into wrappers which will do nothing other than
WH> pull in the appropriate mounts. The sys admin would have to configure
WH> which mounts are local vs network using settings in
WH> /etc/conf.d/{local,net}mount.
WH> What do folks think of these changes?
For local filesystems, mount -a is exactly right and should remain. At
least for those of us who prefer only ever halving to edit fstab(5).
Remote filesystems might be differnt, but for local filesystems the
status quo is better.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/15 04:40 PM, William Hubbs wrote: > On Tue, Aug 04, 2015 at 02:05:12PM -0400, Ian Stakenvicius wrote: >> 1 - if localmount fails, the you end up with everything that >> currently 'need's localmount failing -- this means if you have a >> headless server someplace that reboots, you may not end up with >> an sshd to connect into it just to fix some random localmount >> failure that might not be needed for the core system. So, no, I >> would not like to see localmount failing unless all other >> services are adjusted to no longer need localmount to >> succeed.[**] > > This sounds like more an issue with which file systems are critical > for mounting, and a good argument for getting rid of localmount. > > If we don't care whether localmount succeeds or not, the need > dependency is the wrong one to use. > > Maybe we do think certain file systems must be mounted to boot > successfully, and if we do, those should have need dependencies > and cause failure if they are unable to be mounted, but the others > should not. > > This is a good reason in itself to move away from localmount and > netmount. > > You may have misunderstood what I meant here. Right now, most if not all services expect localmount to have completed successfully before they will start, right? That's the whole reason why localmount as it is now doesn't fail. What you are suggesting here is to make it fail. It doesn't matter whether we use the per-mount service underneath localmount or keep it as a "mount -a" wrapper, in both cases when "localmount" fails we get failures and services wont start. So what you are suggesting here now is that you want to (A) potentially break mounting with the need to externally manage mounts via services in openrc instead of just using /etc/fstab, and (B) also break services if something doesn't start, which is one of the reasons why you wanted to go through with this per-mount service in the first place. My point is that no, we should keep localmount as succeeding even if one of the dependent services fails to mount, *just like it does right now*, *for the same reasons* as it succeeds on failure right now. >> >> Other implementation related questions: >> >> 2 - dependencies in other services: right now we have things >> that need localmount. These will need to be mapped, iirc the >> prototype fork maps them to mount.usr and mount.var instead of >> 'localmount'. So what happens in the case that everything is on >> a single filesystem -- that is, there is no separate mount.usr / >> mount.var? Dependencies break in that case, no? Or will a >> parent mount point 'provide' the subdirectory tree to satisfy >> these mounts? Or will there be a totally different means of >> mapping filesystem parts a service needs with the mount points >> that need to be mounted first? How specific will the needs of a >> service need to be in terms of its mount dependencies in order to >> safely start, if for instance there is no more assurance that >> 'localmount' has started or has successfully finished? > > My thought on this is that if you have a mount.foobar service and > its mountpoint is not listed in fstab, the service would output a > message and return success. This should cover the case of a file > system being needed but not being a real file system. > > From the user's side, you could, if everything was on a single > file system, just use rc_need in /etc/conf.d/* to remove mount.usr > and mount.var from everything. > But what services will shipped init scripts be specifying in depend()?? mount.usr and mount.var are (A) only true in certain cases (things can just as easily be /var/lib , /var/log , /usr/share , etc), and (B) outright wrong if someone just has everything on one root filesystem. Are you suggesting now that not only will everyone have to set up their services / sync them with /etc/fstab but they'll also have to set all mount-point dependencies in their services too? >> 3 - dynamic creation of services -- as of right now, openrc needs >> all services to exist as files/symlinks in /etc/init.d. Is it a >> good idea for a script to be regularly messing with /etc/init.d ? >> Or will openrc be changed to have a whole new means of >> registering dynamically-created services? > > To be honest, I am not really a fan of dynamically created > services; I would rather not go there. We don't do that for net.*, > so I don't think we should for mount.*. > >> 4 - Dealing with dynamic creation of services at bootup -- >> openrc currently generates/refreshes the cache on shutdown or >> during config changes so that it doesn't have to do it on >> startup, thus speeding up startup. Since /etc/fstab could have >> changed between shutdown and startup (and likely not with a >> chroot involved -- say, after moving partitions around in a >> livecd env) then fstab won't match the services (nor the cache) >> anymore. At best this would likely me
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Tue, Aug 04, 2015 at 02:05:12PM -0400, Ian Stakenvicius wrote: > 1 - if localmount fails, the you end up with everything that currently > 'need's localmount failing -- this means if you have a headless server > someplace that reboots, you may not end up with an sshd to connect > into it just to fix some random localmount failure that might not be > needed for the core system. So, no, I would not like to see > localmount failing unless all other services are adjusted to no longer > need localmount to succeed.[**] This sounds like more an issue with which file systems are critical for mounting, and a good argument for getting rid of localmount. If we don't care whether localmount succeeds or not, the need dependency is the wrong one to use. Maybe we do think certain file systems must be mounted to boot successfully, and if we do, those should have need dependencies and cause failure if they are unable to be mounted, but the others should not. This is a good reason in itself to move away from localmount and netmount. > > Other implementation related questions: > > 2 - dependencies in other services: right now we have things that > need localmount. These will need to be mapped, iirc the prototype > fork maps them to mount.usr and mount.var instead of 'localmount'. So > what happens in the case that everything is on a single filesystem -- > that is, there is no separate mount.usr / mount.var? Dependencies > break in that case, no? Or will a parent mount point 'provide' the > subdirectory tree to satisfy these mounts? Or will there be a totally > different means of mapping filesystem parts a service needs with the > mount points that need to be mounted first? How specific will the > needs of a service need to be in terms of its mount dependencies in > order to safely start, if for instance there is no more assurance that > 'localmount' has started or has successfully finished? My thought on this is that if you have a mount.foobar service and its mountpoint is not listed in fstab, the service would output a message and return success. This should cover the case of a file system being needed but not being a real file system. From the user's side, you could, if everything was on a single file system, just use rc_need in /etc/conf.d/* to remove mount.usr and mount.var from everything. > 3 - dynamic creation of services -- as of right now, openrc needs all > services to exist as files/symlinks in /etc/init.d. Is it a good idea > for a script to be regularly messing with /etc/init.d ? Or will > openrc be changed to have a whole new means of registering > dynamically-created services? To be honest, I am not really a fan of dynamically created services; I would rather not go there. We don't do that for net.*, so I don't think we should for mount.*. > 4 - Dealing with dynamic creation of services at bootup -- openrc > currently generates/refreshes the cache on shutdown or during config > changes so that it doesn't have to do it on startup, thus speeding up > startup. Since /etc/fstab could have changed between shutdown and > startup (and likely not with a chroot involved -- say, after moving > partitions around in a livecd env) then fstab won't match the services > (nor the cache) anymore. At best this would likely mean cache > regeneration, at worst it means the services need to be regenerated > first. And then there's the issue of the strictness of the misaligned > mount.* services in the depend() of other services (#1) upon first > boot of the new /etc/fstab. I'm not exactly sure what the answer would be here, except that you would have to keep the symlinks in sync with fstab. I'm thinking that there will be a couple of defaults (mount.usr and mount.var) that will take care of most situations. Like I said though, any ideas would be good. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/08/15 11:29 AM, William Hubbs wrote:
> All,
>
> it seems that we have mostly agreed that this proposal is a good
> one, so I want to focus the discussion on the specific behaviour of
> localmount and netmount.
>
> Currently, they mount all file systems in mass and exit
> successfully regardless of whether the mounts are successful. I
> feel this is a bug because it doesn't correctly report what
> happened, so I want to change their behaviour so they can fail if
> one of the dependent mounts fails.
>
> The other change I want to make, considering that the mount.*
> scripts will actually do the work of mounting the file systems, is
> to turn localmount and netmount into wrappers which will do nothing
> other than pull in the appropriate mounts. The sys admin would have
> to configure which mounts are local vs network using settings in
> /etc/conf.d/{local,net}mount.
>
> What do folks think of these changes?
>
> If they are combined, is this significant enough change to warrant
> a 1.0 version bump?It would be if I were removing local/netmount,
> but I'm not sure whether it is since I'm basically just changing
> the behaviour to fix a bug.
>
> William
>
> if
>
1 - if localmount fails, the you end up with everything that currently
'need's localmount failing -- this means if you have a headless server
someplace that reboots, you may not end up with an sshd to connect
into it just to fix some random localmount failure that might not be
needed for the core system. So, no, I would not like to see
localmount failing unless all other services are adjusted to no longer
need localmount to succeed.[**]
Other implementation related questions:
2 - dependencies in other services: right now we have things that
need localmount. These will need to be mapped, iirc the prototype
fork maps them to mount.usr and mount.var instead of 'localmount'. So
what happens in the case that everything is on a single filesystem --
that is, there is no separate mount.usr / mount.var? Dependencies
break in that case, no? Or will a parent mount point 'provide' the
subdirectory tree to satisfy these mounts? Or will there be a totally
different means of mapping filesystem parts a service needs with the
mount points that need to be mounted first? How specific will the
needs of a service need to be in terms of its mount dependencies in
order to safely start, if for instance there is no more assurance that
'localmount' has started or has successfully finished?
3 - dynamic creation of services -- as of right now, openrc needs all
services to exist as files/symlinks in /etc/init.d. Is it a good idea
for a script to be regularly messing with /etc/init.d ? Or will
openrc be changed to have a whole new means of registering
dynamically-created services?
4 - Dealing with dynamic creation of services at bootup -- openrc
currently generates/refreshes the cache on shutdown or during config
changes so that it doesn't have to do it on startup, thus speeding up
startup. Since /etc/fstab could have changed between shutdown and
startup (and likely not with a chroot involved -- say, after moving
partitions around in a livecd env) then fstab won't match the services
(nor the cache) anymore. At best this would likely mean cache
regeneration, at worst it means the services need to be regenerated
first. And then there's the issue of the strictness of the misaligned
mount.* services in the depend() of other services (#1) upon first
boot of the new /etc/fstab.
[**] Now, if failure of localmount/netmount/other core services
perhaps would trigger a fallover to some sort of 'rescue' runlevel,
where a specific set of services would start anyways (sshd etc), then
I would see this as much less of an issue. Of course if we had that,
then we could set localmount to fail right now in the 'mount -a'
version. This is a completely different topic though.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlXA/tgACgkQAJxUfCtlWe3MvAEAkLE2L5mpiutGa2zemc9m2zYY
YFXC1vWQhrE4OKK9uLgA/RLYGwsOI7MeZVKmYgm1XJicWF68mFbIK/EGRPpMwzyp
=P0Yi
-END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All,
it seems that we have mostly agreed that this proposal is a good one, so
I want to focus the discussion on the specific behaviour of localmount
and netmount.
Currently, they mount all file systems in mass and exit successfully
regardless of whether the mounts are successful. I feel this is a bug
because it doesn't correctly report what happened, so I want to change
their behaviour so they can fail if one of the dependent mounts fails.
The other change I want to make, considering that the mount.* scripts
will actually do the work of mounting the file systems, is to turn
localmount and netmount into wrappers which will do nothing other than
pull in the appropriate mounts. The sys admin would have to configure
which mounts are local vs network using settings in
/etc/conf.d/{local,net}mount.
What do folks think of these changes?
If they are combined, is this significant enough change to warrant a 1.0 version
bump?It would be if I were removing local/netmount, but I'm not sure
whether it is since I'm basically just changing the behaviour to fix a
bug.
William
if
signature.asc
Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/28/2015 06:57 AM, William Hubbs wrote: > On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg) > wrote: >> What would a migration be like? For example, I manage >> filesystems exclusively through fstab (to my knowledge). Would >> this be useful for, say, mounting over the network? What would >> managing FSes with openrc look like? > > 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. > > William > 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. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVuJSnAAoJEAEkDpRQOeFwBdcQALtzqCDnXHI364vVJhWXQRac FRtALTx/RlgG2BS7fclMp5PPC7TYWG4jH50ZD35qozH46JJuhocMwfL02g+FXHIa 1MfaIzXuvhPMotj05PxoaBVBU7TmyhNEFiQJqD7qNu2vgsrknjc2QxXc1+INSgby cfMhmh49nxi6ZxvFAEBXlk2U0RRpomKh/og4NHSd2CiNFDHyg9r2D21S1YAaIAmh n4SHfh1c3y0sDOlhdOaEi6D0a5IGJqM9779LMeKOSjiSGXU+d3Xk+Vhkyo+SXrco 2jk6svz/Sm0XdOz4tCenr/j9PmGSN7UP8QUitoKm+2LmII+ZXkyzWYi5s41knl+2 49fw0fwGKIWJyQKV1f6IHTKOEKaAkxsWIjcmRcVxrQjiZ619ptZJIAv0ILEjZgtr 3/BNV5wiupRuz5aTTnCQdXwBX6wyQnLDsHHLInSjIcM4HCw9Ao2RfEJIAHrS0Sgj rnMV20ixNUgGY+WAv5HXF2HhNNa1ugzuwm+jZqgTjXqubHv9YfUHcJK8ahuWqiN8 IFJde5byla1zom7v+xkwi7rB0WE2La+oGndF+7lxgPkHD5JLtZTzgagYEVVeyFFT xczket5z0LjiRU4GSgucq+vAQUJqyocOprccOn/o5jkRuCexdnLPkZdiMgYzAPN6 cwluPs5OA8LMQPogcrVQ =Q+eI -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Tue, Jul 28, 2015 at 08:45:30PM +0300, Diamond wrote: > On Mon, 27 Jul 2015 17:26:10 -0500 > William Hubbs wrote: > > > - Currently, we have to skip over certain file systems that we can't > > unmount during shutdown. With the new approach, if the mount script > > mounts a file system during boot, it will be able to unmount the > > same filesystem during shutdown, so that will eliminate more > > complexity in our mount/unmount handling. > > What about unmounting during shutdown of things which were mounted by > autofs for example? Let us suppose I have samba network and I mount > shares automatically using autofs in Windows-like way > (cd /net/10.20.30.40/cool_share) and then I reboot after that. Will be > this share unmounted well on shutdown with new system? :) mount-ro isn't going anywhere, so it would end up being remounted read-only as part of the shutdown. Again, that is the way it is currently, but that could easily be changed. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All, I got a clarification on irc that I would like to respond to, and I'll also respond to a couple of other things. On Mon, Jul 27, 2015 at 05:26:10PM -0500, William Hubbs wrote: > All, > > I have been looking over this bug for some time attempting to find a > good solution [1]. > > The original proposal is to add a "want" dependency which would work > like "need" but would not fail if the services wanted did not start [2]. > > I agree that the "want" dependency is a valid feature request. However, I > believe there is a better way to handle the issue in the original bug. > Basically, I want to follow the suggestion in this bug instead [3]. > > My concern about the original proposal is that it will make netmount try > to start all daemons that handle file systems, whether or not they are > actually necessary. It was pointed out to me that, if the want dependency was implemented, fstab could be parsed and want dependencies could be added for the specific network file systems needed. The trend seems to be moving away from relying on fstab contents, so I would rather not add more code that uses fstab unless it is necessary. Besides that, this approach still does not solve another issue I want to solve with separate mount tasks -- you can never know if a mount is successful or not because netmount and localmount must always return success. Concerns about the migration path and preserving legasy behaviour because people may not want to switch to the new system were brought up as well. I'll address the migration path first. I understand that some semblance of localmount and netmount will have to be around for a while until we fix the dependencies in our other services. I haven't figured out yet whether localmount and netmount should be rewritten as wrappers or left as they are for a couple of releases. I guess the easiest might be to leave them as they are for a couple of releases, but I'm not sure yet what the affect on the mount script will be if the mount script tries to mount something that has already been mounted by localmount or netmount. Either way, I'm thinking about adding deprecation messages to them to encourage service script authors to move away from them to depending on the specific file system mounts they need. Now I want to separately address the argument about preserving legasy behaviour just because it is there. Please understand. I'm not saying this to be sarcastic, it is an honest statement. I think providing a transition period to move to using new behaviour is perfectly reasonable, but I have a hard time understanding why old behaviour should be supported indefinitely, especially since users also have the choice to not upgrade packages if they need the old behaviour, and even more importantly, if the new behaviour is an improvement over the old behaviour. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Mon, 27 Jul 2015 17:26:10 -0500 William Hubbs wrote: > - Currently, we have to skip over certain file systems that we can't > unmount during shutdown. With the new approach, if the mount script > mounts a file system during boot, it will be able to unmount the > same filesystem during shutdown, so that will eliminate more > complexity in our mount/unmount handling. What about unmounting during shutdown of things which were mounted by autofs for example? Let us suppose I have samba network and I mount shares automatically using autofs in Windows-like way (cd /net/10.20.30.40/cool_share) and then I reboot after that. Will be this share unmounted well on shutdown with new system? :)
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg) wrote: > What would a migration be like? For example, I manage filesystems > exclusively through fstab (to my knowledge). Would this be useful for, > say, mounting over the network? What would managing FSes with openrc > look like? 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. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/27/2015 03:26 PM, William Hubbs wrote: > All, > > I have been looking over this bug for some time attempting to find > a good solution [1]. > > The original proposal is to add a "want" dependency which would > work like "need" but would not fail if the services wanted did not > start [2]. > > I agree that the "want" dependency is a valid feature request. > However, I believe there is a better way to handle the issue in the > original bug. Basically, I want to follow the suggestion in this > bug instead [3]. > > My concern about the original proposal is that it will make > netmount try to start all daemons that handle file systems, whether > or not they are actually necessary. > > The proposal in [3], on the other hand, is to create a mount script > that works like netifrc. It would mount a single file system, which > would be determined by the link it was called from, much like how > netifrc determines which interface to work on. > > Some of the advantages of this approach are listed in the bug. Here > are a few more I can think of. > > - it will eliminate some of our incompatibilities with busybox [4] > [5]. > > - It will give us honest reports of success or failure with regard > to mounting file systems (netmount and localmount can't do that). > > - Currently, we have to skip over certain file systems that we > can't unmount during shutdown. With the new approach, if the mount > script mounts a file system during boot, it will be able to unmount > the same filesystem during shutdown, so that will eliminate more > complexity in our mount/unmount handling. > > The one down side of the new approach is the migration away from > netmount and localmount. I I will need to keep them as wrappers for > a release or two so we can fix all of our other services that have > dependencies on them. > > I'll also work on making the transition as smooth as possible for > our users. I believe I'll be able to set up the initial symlinks > for the multiplexed mount script based on fstab contents > automatically, but I'm not sure about how much more automation I'll > be able to do. I will automate more as I come across ways to do so, > and I am open to suggestions for how to do so. > > Let me know what you think. > > William > > [1] https://bugs.gentoo.org/show_bug.cgi?id=537996 [2] > https://bugs.gentoo.org/show_bug.cgi?id=406021 [3] > https://bugs.gentoo.org/show_bug.cgi?id=426944 [4] > https://bugs.gentoo.org/show_bug.cgi?id=468600 [5] > https://bugs.gentoo.org/show_bug.cgi?id=468604 > What would a migration be like? For example, I manage filesystems exclusively through fstab (to my knowledge). Would this be useful for, say, mounting over the network? What would managing FSes with openrc look like? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVtugMAAoJEAEkDpRQOeFwBcUQAMb8I39T8ie4S6BWN3+dQ3FC GlzTaTTVn3cghMsjD956T3pwnKVp7Nak4FOEZj19LAciulP+++/me+pIEYMioR5x 3d8237OCgAmSAFk5/ej1wHdQrVR8rOcwgxtqtYLs77RJDwJ1/eMfmlbBzBTpdE8O bmEuVHCJdxvKbp+ZUjka6BTYr7rzpU5w+wUW9SWR3CBW4a1E3JKs9XurGt9JUmTa l1h2Ftw0xZkKXvKt6pJ7obBTrA7fXcuWw/hgvWz4iyofQlsvSmkC+GmIL/nstZMs bBgkTv8idtSNoGZebtM7jxdzIpUnn6j9rZcpo0J5ZQdEDt4xkw6YtfsrMH1mPmI8 2KYzKw/hesVtOtWgyEJvbRbIrrTKA+rKoIxx928dMHVJBqn2/LJa0QUn/oGFaOcX P/5UzzXdDJlbQYKRGH/xU1d5hu/B3DGI6MTgfsGjgr7Bn5+W8PZhO9zcKKJwjxn0 Fl0MD5ibp759ESr07YcjqKOHr0vurc1/Ww9xn9s/gdvcMQxCdzKp/olo3GOxCi66 TjU25hTbUOA6ZuQe/n3zZ+I/ud/uPYbVX6hdT/oNaiCob3PR6zH6/cc8FuVAEryV jqEVrIvnbN+CTi1DTIPAFOPq5PcOvO7NHCLXYqcS3gXH/JEIq0U2+BWdx13s4Whz Run8YkWYZjNl4Fz2a+oA =7yuO -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Mon, Jul 27, 2015 at 6:26 PM, William Hubbs wrote: > > Some of the advantages of this approach are listed in the bug. Here are > a few more I can think of. > As we discussed this is similar to the approach taken by systemd (though it parses fstab and creates service files dynamically). Some other advantages: 1. If a mount fails to load you can reload it using openrc, instead of mount -a (maybe you're using busybox/etc). 2. Services could depend on specific mounts, instead of mounts in general. 2a. If a depended mount fails, then the service fails. If you fix the issue, you can start the service and then trigger the mount automatically, etc. 3. If you want to programatically configure mounts you might be able to avoid fussing with fstab, and instead edit individual mount services. Systemd doesn't infer the mount name from the filename - it is stored inside. Likewise mount options are stored inside the file, so there is no need for fstab to exist. However, in practice most systemd mount units are created by the fstab generator, which dynamically creates/destroys them in /run as fstab changes. -- Rich
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On Tue, Jul 28, 2015 at 02:54:56AM +0300, Alon Bar-Lev wrote: > On 28 July 2015 at 01:26, William Hubbs wrote: > > The proposal in [3], on the other hand, is to create a mount script that > > works like netifrc. It would mount a single file system, which would be > > determined by the link it was called from, much like how netifrc > > determines which interface to work on. > > Hi, > > This is great and consistent with all other services. > > What I would like to see is how to not relay on /etc/fstab content, if > possible. > > If it is like netifrc, there can be fstab module that provides entries > for fstab. > > It can be in /etc/conf.d/filesystem.@name@ instead of openrc core. for > example: I'm not sure what you mean. Right now, I don't see how OpenRC could stop using fstab. I'm open to suggestions though. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
On 28 July 2015 at 01:26, William Hubbs wrote: > The proposal in [3], on the other hand, is to create a mount script that > works like netifrc. It would mount a single file system, which would be > determined by the link it was called from, much like how netifrc > determines which interface to work on. Hi, This is great and consistent with all other services. What I would like to see is how to not relay on /etc/fstab content, if possible. If it is like netifrc, there can be fstab module that provides entries for fstab. It can be in /etc/conf.d/filesystem.@name@ instead of openrc core. for example: --- modules="fstab" config__usr="fstab" # replace /->_ --- Regards, Alon
[gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
All, I have been looking over this bug for some time attempting to find a good solution [1]. The original proposal is to add a "want" dependency which would work like "need" but would not fail if the services wanted did not start [2]. I agree that the "want" dependency is a valid feature request. However, I believe there is a better way to handle the issue in the original bug. Basically, I want to follow the suggestion in this bug instead [3]. My concern about the original proposal is that it will make netmount try to start all daemons that handle file systems, whether or not they are actually necessary. The proposal in [3], on the other hand, is to create a mount script that works like netifrc. It would mount a single file system, which would be determined by the link it was called from, much like how netifrc determines which interface to work on. Some of the advantages of this approach are listed in the bug. Here are a few more I can think of. - it will eliminate some of our incompatibilities with busybox [4] [5]. - It will give us honest reports of success or failure with regard to mounting file systems (netmount and localmount can't do that). - Currently, we have to skip over certain file systems that we can't unmount during shutdown. With the new approach, if the mount script mounts a file system during boot, it will be able to unmount the same filesystem during shutdown, so that will eliminate more complexity in our mount/unmount handling. The one down side of the new approach is the migration away from netmount and localmount. I I will need to keep them as wrappers for a release or two so we can fix all of our other services that have dependencies on them. I'll also work on making the transition as smooth as possible for our users. I believe I'll be able to set up the initial symlinks for the multiplexed mount script based on fstab contents automatically, but I'm not sure about how much more automation I'll be able to do. I will automate more as I come across ways to do so, and I am open to suggestions for how to do so. Let me know what you think. William [1] https://bugs.gentoo.org/show_bug.cgi?id=537996 [2] https://bugs.gentoo.org/show_bug.cgi?id=406021 [3] https://bugs.gentoo.org/show_bug.cgi?id=426944 [4] https://bugs.gentoo.org/show_bug.cgi?id=468600 [5] https://bugs.gentoo.org/show_bug.cgi?id=468604 signature.asc Description: Digital signature
