Hi,
Thanks for your answer.
Yeah it seems to be not so easy to achieve it !...
I'm taking a look to the source, and I think it will be too hard for us
to implement this...
Anyway, I will be very happy if this could be take part in future
version... :)
Regards
--
Erwan
On 03/09/2013 06:31 AM, Ian Kent wrote:
On Fri, 2013-03-08 at 16:05 +0100, Erwan LOAEC wrote:
Hello autofs team,
I use autofs in an heavy production environment with a perpetual flow.
The problem I have is if I add a new cifs share for a given remote
server, this new share never appear under the autofs if the flow is not
stopped.
That's right, multi-mount map entries must completely expire to get
updated.
The main problem with updating active multi-mount map entries is it is
far to easy to completely break automount when trying to umount stale
mount triggers and adding new mount triggers, not the least of which is
the possible incompatible changes to hierarchic dependence within the
multi-mount mount tree.
Is there a way to schedule a periodic refresh the share list ?
Nope.
For now I use autofs 5.0.6 (with about 50 patchs: the last one is
autofs-5.0.6-fix-configure-string-length-tests.patch). I've look into
the next version/patch, I didn't see anything related to my problem...
OS version: Debian squeeze (kernel 2.6.32)
There is a fairly recent patch series that attempts to allow the
internal hosts map to update host exports when a HUP signal is received.
That method could be extended (which I intended to do at some stage) to
cater for updating multi-mount map entries on receiving HUP signal.
The incompatible hierarchic dependence issue is still the main concern.
Extending this to program maps, like the example program map auto.smb,
is not so simple because there is currently no way for a program map to
enumerate itself, so the map can't be updated with a HUP signal. IOW
there's no read map function defined in the autofs program map module.
More than that autofs can't know how to get an updated entry other than
calling the program map lookup module mount function which currently
will also, unconditionally, attempt to mount the entry.
So it isn't a straight forward problem to solve either.
Ian
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
