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

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

[Christian Bornträger]

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.

Other approaches like the integration in KDE have the problem,  to be only 
useful for KDE-programs - that means shares connot be used by all programs. 
(e.g. xmms cannot play an mp3 residing on a smb-share under kde without using 
smbmount)

Therefore I had the idea, to implement this smb-browsing feature in kernel 
space. It will be a kind of network neighbourhood-filesytem with all 
computers as top level directories below the mount point.

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

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)?

If I get positive response I will try to implement this feature. As it will 
be my first work on implementing a file system it might take some time, but I 
think it is a good chance to learn a lot about the linux kernel.

greetings

Christian

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

[Oliver Neukum]

> Therefore I had the idea, to implement this smb-browsing feature in kernel
> space. It will be a kind of network neighbourhood-filesytem with all
> computers as top level directories below the mount point.

What could a kernel space browser do that a demon could not do ?

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

Do you say that autofs cannot be used to mount smbfs shares ?

> 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)?

Smbfs itself must be in kernel. That doesn't imply that the browser has to
be in kernel.

	Regards
		Oliver

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

[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

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

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0201191313170.4434-100000@cola.teststation.com>
By author:    Urban Widmark <urban@teststation.com>
In newsgroup: linux.dev.kernel
> > 
> > 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.
> 

There is probably no need to even do that.  SMB contains a browser
list protocol, and Samba (nmbd) can participate in it.  You should be
able to read it out of there.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

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

[Mark H. Wood]

On 19 Jan 2002, H. Peter Anvin wrote:
> Followup to:  <Pine.LNX.4.33.0201191313170.4434-100000@cola.teststation.com>
> By author:    Urban Widmark <urban@teststation.com>
> In newsgroup: linux.dev.kernel
> > >
> > > 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.
> >
>
> There is probably no need to even do that.  SMB contains a browser
> list protocol, and Samba (nmbd) can participate in it.  You should be
> able to read it out of there.

Yes.  Consider the way DNS is implemented, and do likewise.  That is,
there's a library which presents a single standard interface for mapping
names (shares, hosts, whatever) to addresses in the NMB namespace.  It
can be configured to use a local nmbd if you have one, a nearby nmbd if
you choose, LDAP searching of the local ADS forest if there is one, etc.
without reconfiguring the app.s.

It might even be grafted onto the existing resolver library, although the
name resolution API may be due for an overhaul to generalize it over a
wider variety of name resolution services.

How the results are presented to app.s is a separate question, and I
believe that there are methods of implementing filesystems almost entirely
in userspace.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Our lives are forever changed.  But *that* is exactly as it always was.

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

[H. Peter Anvin]

Followup to:  <E16RtOX-0007Ao-00@mrvdom00.kundenserver.de>
By author:    Christian =?iso-8859-1?q?Borntr=E4ger?= 
	<linux-kernel@borntraeger.net>
In newsgroup: linux.dev.kernel
> 
> 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)?
> 

It REALLY should be in user space.  Putting this kind of crap in the
kernel is insane.  Note also that *browsing* (network 'hood) is
different from *mounting* -- even on Windows it is very common that
there are computers you can't see in your browse windows that you can
access by name.

Consider DNS -- it *used* to be possible to enumerate DNS (these days,
most servers will deny access to you if you try), but it has been a
long, long time since it was ever practical.  However, you can do
blind resolution quite trivially.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>