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

2015-08-01 Thread William Hubbs
On Fri, Jul 31, 2015 at 05:29:37PM -0700, Patrick McLean wrote:
> On Fri, 31 Jul 2015 17:28:03 -0500
> William Hubbs  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.
> > 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.

Thoughts?

William



signature.asc
Description: Digital signature


[gentoo-dev] [warning] the bug queue has 87 bugs

2015-08-01 Thread Alex Alexander
Our bug queue has 87 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!



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

2015-08-01 Thread Patrick McLean
On Sat, 1 Aug 2015 10:05:44 -0500
William Hubbs  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  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.
> > > 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
>