Re: [gentoo-dev] rfc: openrc mount service prototype

[Patrick McLean]

On Sat, 1 Aug 2015 10:05:44 -0500
William Hubbs <williamh@g.o> wrote:

> On Fri, Jul 31, 2015 at 05:29:37PM -0700, Patrick McLean wrote:
> > On Fri, 31 Jul 2015 17:28:03 -0500
> > William Hubbs <williamh@g.o> wrote:
> >
> > > On Fri, Jul 31, 2015 at 11:57:59PM +0200, Peter Stuge wrote:
> > >
> > > What I'm asking about is whether anyone knows of a smoothe way to
> > > transition users from local/netmount to mount.<filesystem>
> > > dependencies, without breaking systems. If that doesn't exist, 1.0
> > > will have to sit in p.mask until major packages catch up.
> >
> > You could make "localmount" and "netmount" scripts that
> > read /etc/fstab and generate "need" dependencies on the network or
> > local filesystems that exist in there. That should emulate current
> > behaviour with the new system.
>
> This is exactly what I'm thinking about. Researching this as I go, there
> are reasons to keep localmount and netmount around, but I want to
> rewrite them to depend on mount.*.
>
> There will still be a change in behaviour, because localmount and netmount
> never fail in the current setup, but they potentially will in the new setup
> based on whether or not one of the file systems they depend on fails to mount.
>
> I'm a bit concerned about trying to auto generate dependencies in them,
> for the same reason I'm concerned about auto generating dependencies in
> netmount as it currently stands.
>
> All of this processing would be in the depend() function, and would be
> run every time the OpenRC dependency cache is regenerated. The best way
> to process fstab is with the fstabinfo helper, but every time you run
> it, that is a possible full scan of fstab, and I worry that that would
> slow down dependency cache regeneration for servers with many file
> systems. If I don't use fstabinfo, I"m basically re-inventing the wheel
> and writing code in sh to parse fstab.

You could use fstabinfo or findmnt for processing it, but it does not
need to do all the processing, you could cache the results and only
regenerate when the mtime on the fstab is newer than the cache.

On the other hand, unless your fstab is extremely large, it's unlikely
this processing will take particularly long, fstab files tend to be
pretty short (less than 100 entries), and that is not exactly a large
dataset.

>
> Thoughts?
>
> William
>