I saw a note that direct mounts are not supported on Linux; is this true
even for autofs? Or only for user-space stuff like am-utils?
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT: HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
%% Scott Mcdermott <[email protected]> writes:
sm> mostly nowadays, `pwd' is a shell builtin that doesn't use the
sm> algorithm you refer to, if I understand right (like /bin/pwd has
sm> to use, eg keep going ..) instead keeping track internally.
Well, sure, but there's still getcwd() ... :)
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Paul Smith on Tue 21/01 01:05 -0500:
> sm> mostly nowadays, `pwd' is a shell builtin that doesn't use the
> sm> algorithm you refer to, if I understand right (like /bin/pwd has
> sm> to use, eg keep going ..) instead keeping track internally.
>
> Well, sure, but there's still getcwd() ... :)
which is also kept track of in the shell (talking about bash only, don't
know what other shells do)
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
%% Scott Mcdermott <[email protected]> writes:
>> Well, sure, but there's still getcwd() ... :)
sm> which is also kept track of in the shell (talking about bash only,
sm> don't know what other shells do)
No, I mean getcwd(3), the C runtime library function... if my program
invokes this then it doesn't matter what the shell does.
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Paul Smith on Tue 21/01 02:05 -0500:
> No, I mean getcwd(3), the C runtime library function... if my program
> invokes this then it doesn't matter what the shell does.
Not if you chdir("/") like a good little daemon
yeah I know, I get your point :) If that is the only argument against
direct mounts though, I really don't understand statements like
"[Autofs. Will. Never. Support. Direct. Maps. Period. Full Stop.]"
(see autofs mailing list archives from H. Peter Anvin)
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
%% Scott Mcdermott <[email protected]> writes:
sm> Paul Smith on Tue 21/01 02:05 -0500:
>> No, I mean getcwd(3), the C runtime library function... if my program
>> invokes this then it doesn't matter what the shell does.
sm> Not if you chdir("/") like a good little daemon
Well, not everything that I run is a daemon... and yet it still may need
to run getcwd() :).
sm> yeah I know, I get your point :) If that is the only argument
sm> against direct mounts though, I really don't understand statements
sm> like "[Autofs. Will. Never. Support. Direct. Maps. Period.
sm> Full Stop.]"
sm> (see autofs mailing list archives from H. Peter Anvin)
I dunno either. Maybe this has more to do with the unclean hacks
required to implement direct mounts in the kernel than the issues the
user has with direct mounts from the outside.
Anyway, this is probably pretty OT for this list, and it's time for me
to go to bed!
Thanks all...
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 21 Jan 2003 02:05:28 -0500, Paul Smith <[email protected]> wrote:
> %% Scott Mcdermott <[email protected]> writes:
>
> >> Well, sure, but there's still getcwd() ... :)
>
> sm> which is also kept track of in the shell (talking about bash only,
> sm> don't know what other shells do)
>
> No, I mean getcwd(3), the C runtime library function... if my program
> invokes this then it doesn't matter what the shell does.
getcwd() on a modern Linux kernel (2.2 or newer) is a system call so the
library doesn't need to play any tricks with stat() and readdir(). Thus
it doesn't matter how many direct mounts you have.
Of course, this is a Linux-only optimization, other systems will still
have the same old problems if a mount hangs.
As for the direct mount support in am-utils:
- Linux autofs doesn't support direct mounts. Period. It's a kernel
limitation, and nothing amd does can work around it. So if you're
using amd in it's new autofs mode, direct mounts won't work. I think
we try to emulate them using the non-autofs mode, but read the next
paragraph...
- The trick amd uses (currently) to provide direct-mounts is rather ugly:
it mounts a filesystem (its own) and then it claims that the root of
that filesystem is a symlink. Crossing that symlink is what triggers
the automount. The kernel gets rather upset about this, because it
makes the (rather reasonable) assumption that the root of a filesystem
is always a directory.
I haven't looked into this for some time, but indeed, the kernel patch we
used to provide stopped working around 2.4.10 or so. Al Viro suggested an
alternative way of implementing direct mounts, using bind mounts, but there
are a few problems with it:
- It's very Linux-specific. Not an insurmountable problem, but a headache
nonetheless.
- It necessarily needs to know a _lot_ about the kernel internals,
specifically about the order in which the kernel does calls to the
filesystem during path_walk() -- and cached_path_walk() -- so that
we trigger the mount at the right time, not too early and not too late.
This is bound to break on a lot of kernel versions, and is a nightmare
to maintain, especially in a package like am-utils that strives to be
relatively OS-independent.
I'm willing to look over patches that implement the bind-mount alternative,
or I may even do it myself when I get way too much free time on my hands
(heh!). Nevertheless, due to the above reasons, direct mounts will always
be a second rate citizen on Linux.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
http://www.ictp.com/training/sourceforge.asp
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Paul Smith on Mon 20/01 13:02 -0500:
> I saw a note that direct mounts are not supported on Linux; is this
> true even for autofs? Or only for user-space stuff like am-utils?
It is true only for autofs. Of course "mount server:/path /mount/point"
will always work :)
Word has it that the am-utils now speaks autofs to the kernel, and does
support direct mounts (among other things), so one can have the best of
both worlds (speed and features)
Now we can finally get along in a Sun environment without hacks.
autofs has its own mailing list btw
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
%% Scott Mcdermott <[email protected]> writes:
sm> Paul Smith on Mon 20/01 13:02 -0500:
>> I saw a note that direct mounts are not supported on Linux; is this
>> true even for autofs? Or only for user-space stuff like am-utils?
sm> It is true only for autofs. Of course "mount server:/path
sm> /mount/point" will always work :)
Well, I kind of meant automounting, so autofs and am-utils :).
I know that am-utils doesn't support it, and a note in their docs seems
to imply that the Linux kernel itself doesn't support it... so I was
curious if autofs supported it.
For example, am-utils on FreeBSD does support direct mounts IIRC.
sm> Word has it that the am-utils now speaks autofs to the kernel, and
sm> does support direct mounts (among other things), so one can have
sm> the best of both worlds (speed and features)
Interesting!
sm> Now we can finally get along in a Sun environment without hacks.
Well... except for direct mounts. We can all agree that they are evil
and they suck, but the fact remains there are a lot of them out there
and they are often hard to get rid of...
sm> autofs has its own mailing list btw
OK, thanks.
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Paul Smith on Mon 20/01 21:48 -0500:
> I know that am-utils doesn't support it,
hmm direct mounts? well according to the docs:
The Linux kernels don't support Amd's direct mounts very well,
leading to erratic behavior: shares that don't get remounted
after the first timeout, inability to restart Amd because its
mount points cannot be unmounted, etc. There are some kernel
patches on the am-utils Web site, which solve these problems.
(I think this is talking about using the autofs support in beta
am-utils)
so I guess you need a patch, hmph.
> Well... except for direct mounts. We can all agree that they are evil
> and they suck, but the fact remains there are a lot of them out there
> and they are often hard to get rid of...
I don't agree that they are evil or that they suck. Some mounts are
static and won't change, and just a simple mount will suffice. What's
wrong with using a direct mount in this case (maybe /home/ or
/var/spool/mail/)? Is there a real argument against this besides "the
performance sucks when the directory gets large" (which is an admin
decision I think). I don't really know, we don't have large enough
directories that it becomes a problem. One other good thing about
direct mounts is that you can immediately `ls' the directory and see all
the possible entries, but this could be implemented in other ways.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
%% Scott Mcdermott <[email protected]> writes:
sm> hmm direct mounts? well according to the docs:
sm> [...]
I saw that, but then there was another note saying that as of kernel
2.4.10 they had removed the "direct mount hack" and now direct mounts
were totally unsupported. I'll have to go back and find that again.
>> Well... except for direct mounts. We can all agree that they are
>> evil and they suck, but the fact remains there are a lot of them
>> out there and they are often hard to get rid of...
sm> I don't agree that they are evil or that they suck. Some mounts
sm> are static and won't change, and just a simple mount will suffice.
sm> What's wrong with using a direct mount in this case (maybe /home/
sm> or /var/spool/mail/)? Is there a real argument against this
sm> besides "the performance sucks when the directory gets large"
sm> (which is an admin decision I think). I don't really know, we
sm> don't have large enough directories that it becomes a problem.
sm> One other good thing about direct mounts is that you can
sm> immediately `ls' the directory and see all the possible entries,
sm> but this could be implemented in other ways.
Well, if you mount directly in / it can be a big problem, since commands
like pwd etc. often use an algorithm that can hang if one of your direct
mounts in / is unavailable.
I suppose if you mount below / it's not so bad, but my understanding is
that every direct mount uses up resources even if it's not mounted, so
as you say if you have a lot of them it's a problem (and we do have a
lot, unfortunately).
--
-------------------------------------------------------------------------------
Paul D. Smith <[email protected]> HASMAT--HA Software Mthds & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Paul Smith on Mon 20/01 22:53 -0500:
> Well, if you mount directly in / it can be a big problem, since
> commands like pwd etc. often use an algorithm that can hang if one of
> your direct mounts in / is unavailable.
mostly nowadays, `pwd' is a shell builtin that doesn't use the algorithm
you refer to, if I understand right (like /bin/pwd has to use, eg keep
going ..) instead keeping track internally.
but your point is a good one :)
(if only umount -f worked hehe see recent list archives)
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs