On 10 Nov 1999, Anders Melchiorsen wrote:
> Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> You know, I was going to write this project off as being too simple,
Depends on how you go about doing it.
> until I got your e-mail. Right now I am not entirely sure anymore. It
> seems like everyone says it should be not-too-hard, but no-one has
> tried actually implementing it.
I've tried, I've just failed to do it well. Like I said, I've got 600
lines of perl that does basically what we want, but does so at the
expense of wasting 99% of the network bandwidth and CPU time it uses.
> > Exactly. I've thought of some hacks to do this, but they all involve
> > either writing a new autofs module, writing a new vfs driver, or doing
> > hideous loopback mounts of small ext2 image files.
>
> Are you backing away from this because it is bad design, or a lot of
> work?
I'm don't want to write a new autofs module because it's a lot of work
and bad design. I don't want to do that loopback mount hack because
it's *really* bad design (although my only major qualms are
performance concerns; I am going to give it a try and see how it turns
out...). And I don't want to write a new vfs driver because, even
though it seems like the Right Thing to do, it's the most work of the
lot.
> Do you have an idea how much work it would be? I have not really
> looked at the implementation of this stuff before so I have a hard
> time giving an estimate.
My current script is ~500 lines, and modularizing that and converting
it into a daemon (to handle server lists) and a program map script, to
do the smbfs mounts and the loopback mounts... it would certainly
still fall under 1000 lines.
The existing smbfs driver is ~5000 lines of C, so I suspect adding
browsing capabilities to that would add another few thousand.
I don't know how much work a new autofs module would be. It's enough
of a kludge that I couldn't see it being accepted into the main source
tree anyway.
> I am willing to spend quite some time on it, provided I can get it
> accepted as a student project. The problem is that I cannot do that if
> it is too simple - or too hard for that matter :).
You know what you could do - if the existing smbfs driver were
extended to allow server-at-a-time mounting (i.e.
"mount -t smbfs //servername /mount/point", so that each share
appeared as "/mount/point/sharename"), then making autofs handle
mounting a server at a time (and having a daemon refresh the server
lists - my perl script would work, or you could even hack nmbd) would
be pretty simple. I hadn't thought about it before, but that would be
the best way to go about it.
The only thing that bothers me is the vfs change from Linux 2.2 to
2.3. I don't know if smbfs has even been updated for 2.3 yet, and I'd
hate to do a lot of C coding on the 2.2 version when it will be
obsolete in a few months.
> > Plus the whole "smbmount" thing is shaky at best. I advise giving up
> > on the smbfs specific support in autofs, and simply making sure your
> > system is configured so that "mount -t smb" and "mount -t smbfs" work
> > as expected.
>
> I cannot really figure out how smbmount, smbclient, and smbfs are
> related. Do they use the same code to get a file over the network, or
> are they seperate entities?
smbmount is just a special mount command to mount smbfs shares. If
you get things working nicely you should be able to do a "mount -t
smbfs", let smbmount get called behind the scenes, and forget it
exists.
smbclient is the Samba-supported ftp-like client to access SMB shares
from a CLI interface.
smbfs is the illegitimate baby of the three that nobody wants to try
maintaining. I think Andrew Tridgell recently volunteered to maintain
smbfs, but for the year or two previous, questions about smbfs only
elicited loathing from the Samba people who didn't want to work on
Linux-only code and who didn't want to hear complaints/bug reports on
it.
There's also smbsh now, which apparantly preloads a shared library
that intercepts the normal libc open(), etc. commands to make
dynamically linked apps think you've got a smbfs filesystem mounted
when you really don't. This is what most Samba people want to support
instead of smbfs, since it works on commercial Unices where they can't
add a new filesystem to the kernel.
Apologies to all the autofs mailing list people; this is straying off
topic. Say the word and we'll take it to private email.
---
Roy Stogner
