Re: [question] implentation of smb-browsing: kernel space or user

[Urban Widmark]

On Sat, 19 Jan 2002, Christian Bornträger wrote:

> Hello,
> 
> I think that using the smb-file-system with a user-space mounter like 
> mkautosmb has the problem of bad scalability in large networks, because it 
> scans the whole network before you can access one share.

You don't need to scan on every access. You could run the scanner only if
it was more than x minutes since the last scan. You could run the scanner
independently of any attempts to access autofs.

> The first step might be to glue the autofs with smbfs and add a kernel smb 
> browser as a proof of concept.

autofs works fine with smbfs as it is (except for not allowing space in
the share names, but that belongs on a different mailinglist and isn't
smbfs specific).

I think you can do what you want with an executable autofs map and some
network scanning daemon that "knows" what the smb network looks like.
Perhaps samba's nmbd can be made to talk to it.

You could build a browsing tool that would work on any OS with an
automounter (BSD has a smbfs too, nowadays).

Or just use LinNeighbourhood (http://www.bnro.de/~schmidjo/)

> My question is: Do you think, that this kind of filesystem is sensible, or do 
> you think that smb-stuff has to be in user space. (for example using the 
> filesystem in userspace approach, shown some weeks ago)?

I see no advantage of doing the browsing in kernel space. You want to use
the samba codebase as much as possible.

The advantage of having smbfs in the kernel is speed (current
implementation doesn't really take full advantage of that ...). You can do
smbfs as a userspace filesystem, possibly re-using libsmb from samba. It 
has been suggested before.

/Urban