From: "Ruslan U. Zakirov" <cubic@wildgate.miee.ru>
To: Ian Kent <raven@themaw.net>
Cc: autofs mailing list <autofs@linux.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: making the mountpoints visible all the time (fwd)
Date: Fri, 21 Nov 2003 11:49:17 +0300 [thread overview]
Message-ID: <3FBDD18D.1030409@wildgate.miee.ru> (raw)
In-Reply-To: <Pine.LNX.4.33.0311211453250.6131-100000@wombat.indigo.net.au>
Ian Kent wrote:
>On Thu, 20 Nov 2003, H. Peter Anvin wrote:
>
>
>
>>Ian Kent wrote:
>>
>>
>>>To fit in with the existing framework I would need to require the entire
>>>map returned for a NULL key.
>>>
>>>
>>>
>>That's correct.
>>
>>
>>
>>>>And of course autofs needs to deal with the consequences of the map
>>>>changing underneath it.
>>>>
>>>>
>>>I normally reread the map and try again on lookup failure. There is the
>>>HUP signal to do a manual map reread.
>>>
>>>
>>>
>>A better option is probably to update periodically. You still need to
>>be able to handle query of a mount point that you don't know about
>>(might have appeared anew) or a mount point you thought exist not being
>>found.
>>
>>
>
>The above works that way without the update.
>
>I'm not sure that a periodic update really gets us much. Since in most
>sites maps change infrequently.
>
Runtime configureable? I think somebody can be interested in
'timeinterval updates',
some in 'just before request' or 'never'(could be done in map itself).
>
>On the other hand at work we run a cron every night on all our machines to
>trigger an update of the maps.
>
If I return to my task then I have two solutions:
1) User space daemon that cache all needed info about workgroup. So it
wouldn't be
much overhead to touch programm map on every request.
2) Programm map do all things only when it's called without arguments.
Sometimes
network can take much time to finish and I have to use periodicaly
update calls(~30min).
So I vote for runtime configuration of interval:
value > 0 - time period in seconds(msec,min or other)
value = 0 - every time
value < 0 - never
I think it's normal to configure it due userspace daemon startup.
>
>So I'm on the fence here?
>
>
>
Best regards. Ruslan.
next prev parent reply other threads:[~2003-11-21 8:49 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-19 8:13 making the mountpoints visible all the time (fwd) Ian Kent
2003-11-19 16:45 ` H. Peter Anvin
2003-11-21 0:51 ` Ian Kent
2003-11-21 1:43 ` H. Peter Anvin
2003-11-21 6:59 ` Ian Kent
2003-11-21 8:49 ` Ruslan U. Zakirov [this message]
2003-11-22 7:14 ` Ian Kent
2003-11-21 19:52 ` H. Peter Anvin
2003-11-21 19:56 ` H. Peter Anvin
2003-11-22 7:19 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2003-11-17 5:05 Chris Croswhite
2003-11-17 5:32 ` Ian Kent
2003-12-02 13:49 ` Ian Kent
2003-11-16 16:05 Ian Kent
2003-11-16 19:58 ` Alexander Macdonald
2003-11-17 2:53 ` 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=3FBDD18D.1030409@wildgate.miee.ru \
--to=cubic@wildgate.miee.ru \
--cc=autofs@linux.kernel.org \
--cc=hpa@zytor.com \
--cc=raven@themaw.net \
/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.