On Mon, Sep 24, 2012 at 03:48:56PM +0400, Michael Tokarev <[email protected]>
wrote:
> I mean, I don't want to break users' boxes like in your case
> because some option is no longer recognized. Accepting it and
> doing nothing (or printing a warning) is not a big deal really.
Ahh, so your plan is to ignore it, not make it work.
> > that breaks the test for bind mounts so it thinks bind mounts do not work.
> > That works fine for me as I haven't found any use for bind mounts yet, but
> > have lots of problems (as reported, but not being able to unmount local
> > filesystem without ALSO taking care of automount is annoying as wlel :).
>
> Well, it was meant as an optimisation. Maybe these can also be
> addressed somehow. Note that nfs-mounts wont let you to umount
> local filesystems too. But okay.
But bind mounts do let me unmount local filesystems, except, the umount
succeeds and the filesystem stays mounted in the automount dir. With
symlinks, I can't unmount the filesystem because it is busy.
That's ok of course, the issue is that the admin normally has the option,
except with automount.
Furthermore, this recursive bind mount issues have been fixed
countless times but always keep coming back (or keep not being fixed
completely). Symlinks just work race-free, which makes them quite sexy to
mem in addition to all the other advantages they come with :)
> > Well, I have the obligation to test :) I'll install it later and see if I
> > can replicate the test (maybe give me a few days :).
>
> Actually you don't have any obligations here. The thing is: you
> reported a bug, and I see it is now fixed, at least here for me it
> works now without segfaulting.
>
> I was mostly asking you about any OTHER issue you may also have, since
> you appears to have a good love for autofs and its issues :)
I keep hitting these races and problems indeed. I'll try to see if
automount now "just works" with bind mounts, and keep patching it for
the other advantages of symlinks.
> > - they usually have to administrate a flock of boxes that just need to
> > work somehow :)
>
> I "fixed" it here by using static fstab entries at the end. Annoying,
> but autofs didn't fix an issue for me which I hoped it to fix. To me
> the problem was for two servers to be able to boot them in any order
> without one failing because another isn't booted up yet. One mounts
> nfs share from another, so automount fixes this mount issue (when it
> works ofcourse!), but these mounts are used by other software (it is
> Oracle database in our case), and it fails anyway without seeing the
> dirs. So.. no difference in the end result.
I don't know in which order debian does things these days (I don't sue
it's init system), but I found that things work much more smoothly if NFS
exports are done _before_ the network goes up (and conmversely, are not
unexported until the network is gone). Combined with long enough timeouts
for any boots, could that work for you? (I probably don't fully understand
your issue, so I may be utterly wrong :).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
