All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Gordon Lack <gml4410@ggr.co.uk>
Cc: autofs@linux.kernel.org
Subject: Re: autofsv5 enhancement - map names in /proc/mounts
Date: Tue, 14 Nov 2006 10:00:07 +0800	[thread overview]
Message-ID: <1163469607.3297.22.camel@localhost> (raw)
In-Reply-To: <4558A441.1030303@ggr.co.uk>

On Mon, 2006-11-13 at 16:58 +0000, Gordon Lack wrote:
> Ian Kent wrote:
> >>     Given that there can only be one map active at a mountpoint, and the 
> >> first one wins (which is why the -null map works) that would be 
> >> /etc/auto.server1.home,
> > 
> > Ya but for some reason I believed that I was able to do this with the

"believed", past tense.

> > Solaris automounter and so v5 now will merge each map.
> 
>     Just tried it on Solaris8:
> 
> Added these to /etc/auto_master:
> 
>   /local/AM /etc/auto.AM1
>   /local/AM /etc/auto.AM2
> 
> /etc/mntab now has *just* this 1 line at the end:
> 
>   /etc/auto.AM1   /local/AM       autofs  indirect,..........
> 
> and only the entries in /etc/auto.AM1 work.
> 
> This is what I would expect.  eg: -null is there so that you can 
> "remove" an entry from an included NIS  auto.master (or equiv).  If the 
> code is merging then this won't work, and its supposed to.
> 
> It's also perfectly reasonable to have, say, a standard auto.master map, 
> and a smaller auto.master.wizards map, with maps in it which are meant 
> to *override* the standard ones.
> 
> I can't see any benefit in merging things here - only confusing 
> complexity.  On Solaris and Irix (and Linux up to autofsv4) I've only 
> ever seen the first map mentioned be used (OSF1 uses the last, which is 
> truly bizarre, as it creates mountpoints then has to immediately rip 
> them out in order to replace them...)

I did this because I believed I had used this in Solaris previously.
I'm still deciding whether to change the semantics.

The "-null" handling is incorrect atm as well.
I'm fixing that now.

And as far as allowing multiple maps per indirect mount point goes,
there was another reason for this. In autofs v4 there is a map type
called "milti-map" where multiple map names can be given and this allows
such maps to be migrated to v5. The "-null" map handling will now be
setup to white-out all further occurrences of the nulled mount point. 

As far as adding the map name goes I haven't finished checking the
Solaris behavior yet.

> 
> > An individual file name can be up to 255 characters alone.
> > They don't have to have spaces to be long.
> 
>     Agreed - but is there a limit to the line lengths or total size of 
> /proc/mounts?

Not sure. I'd have to refer to the source.

> 
> > How do you use this feature?
> 
>     I have a script which reads it and prints the actual mounts that 
> exists at a given automount point.  It means I don't need to find out 
> which map is handling a particular automount point, nor do I have to 
> type in the map name, and I get the keys sorted for me.

I'd like to find a simple way to accommodate this while retaining the
multiple map functionality.

Ian

  reply	other threads:[~2006-11-14  2:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-07 15:02 -hosts and -null enabling for autofs v4.1.x Gordon Lack
2006-07-13 13:10 ` Ian Kent
2006-07-13 13:42 ` Jeff Moyer
2006-07-14 11:33   ` Gordon Lack
2006-07-14 13:31     ` Jeff Moyer
2006-07-14 15:58       ` Gordon Lack
2006-08-07  6:56         ` Ian Kent
2006-08-22 14:03 ` Bug (and patch) in autofs init.d script (v4.1.4) Gordon Lack
2006-08-22 14:18 ` Enhancement patch for autofs v4.1.4 init.d script Gordon Lack
2006-09-08 11:31   ` Bug in autofs v4.1.4 init.d script (and fix) Gordon Lack
2006-09-12 12:58     ` Bug in autofs v4.1.4 init.d script for reload " Gordon Lack
2006-09-13  9:42       ` Gordon Lack
2006-11-10 11:58 ` autofsv5 bug. Non-existent dirs get "mounted"! Gordon Lack
2006-11-10 12:05   ` autofsv5 enhancement - map names in /proc/mounts Gordon Lack
2006-11-10 17:33     ` autofsv5 - mouting files (not dirs) Gordon Lack
2006-11-11  2:58       ` Ian Kent
2006-11-11  2:53     ` autofsv5 enhancement - map names in /proc/mounts Ian Kent
2006-11-13 10:09       ` Gordon Lack
2006-11-13 15:44         ` Ian Kent
2006-11-13 16:58           ` Gordon Lack
2006-11-14  2:00             ` Ian Kent [this message]
2006-11-14 10:00               ` Gordon Lack
2006-11-14 11:42                 ` Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1163469607.3297.22.camel@localhost \
    --to=raven@themaw.net \
    --cc=autofs@linux.kernel.org \
    --cc=gml4410@ggr.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.