On Wed, 10 Nov 1999, Roy Stogner wrote:
> 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.
Yes ... something like what devfs does? Creating directories for each
server it finds (each server it's userspace daemon finds), creating
subdirectories for each share (when someone accesses the dir). And somehow
fitting autofs in there to actually mount things.
Now, to do this you need to understand dentries, inodes, page cache (used
by readdir, no?) and other nifty vfs things. That in itself, understanding
and describing seems like a pretty good project to me. To this you add
using this knowledge to add to the existing system.
It's a student project. This can't be considered too easy. Does it have to
become complete/work perfectly to write and present a report? Usually it's
what you write that is important and that what you have done isn't crap
and that you have an idea on how to improve the things that doesn't work.
You may also want to check the GPL-ability of your work. In some places
the school (University?) owns some rights to your work.
> > 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.
I'd say a month of searching for info, reading kernel code, writing little
notes to explain to yourself what this is about, writing/modifying
testcode that crashes your machine. Then another month of seriously trying
to implement it. And then one to clean it up so that you can present it :)
I'm of course just guessing. And any hard to solve problems are likely
beyond this. But that sort of time should produce something, and it should
be something worth doing and fun. Maybe you could talk to some vfs-gurus
on linux-kernel? They may very well tell you that this is insane ...
(doesn't mean that you have to listen to them of course :)
> 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 think extending smbfs is the right idea here. smbfs does one
thing, this browsing is separate and should be a separate piece. It could
be extended to search for NFS exports, and netware equivalents. Maybe
there is no need for that, but they could be used as a thought experiment
to make it generic.
I don't see how it needs to be connected to smbfs at all. The userspace
daemon finds things and tells this to the vfs module, that adds and
removes directories (what am I saying? why can't the daemon use
mkdir/rmdir?). Then autofs mounts it, like it would any other fs. Maybe
autofs needs modification to handle a very dynamic type of map, or maybe
it doesn't.
> > 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 :).
Don't ask us, ask your teacher/instructor :)
> 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.
Ah, I should have read your entire mail before starting to write an
answer. I agree, except that it should be browsefs (or nnfs?) and there
shouldn't be any need to mount the entire server at once. Just create the
dirs and an autofs map and it should sort itself out.
> 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
Yes it has. I did some work converting some things from 2.0 (and much to
my surprise they worked) and then Alexander Viro updated it to follow some
other changes. 2.3.18 should work with a patch I made (this broke sometime
later, don't know about 2.3.19). smbfs in 2.3.24 is broken. 2.3.25 should
work again (I haven't yet made it boot ...)
> 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.
samba 2.0.6 should be out "real soon now", with smbmount as mount.smb.
mount -t smb is here to stay (yes, hpa, I know ... make a symlink to
mount.smbfs :)
> 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
Correct.
> There's also smbsh now, which apparantly preloads a shared library
> that intercepts the normal libc open(), etc. commands to make
I believe there was some problems with recent glibc's? Some internal
structure that is needed, that no longer is exported.
> Apologies to all the autofs mailing list people; this is straying off
> topic. Say the word and we'll take it to private email.
echo Apologies
I'm also interested in this and I'd appreciate being included in any
private mail discussions.
--- begin, really off topic ---
Since you are probably using smbfs if you've read this far, I'm throwing
in this as well:
http://www.hojdpunkten.ac.se/054/samba/
"smbfs fails to list all directories" on a certain dir I can't get smbfs
to work without modifying smbfs. If you have the time, please test this
and report to me.
/Urban
