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
> 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
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
Followup to: <[email protected]>
By author: Christian =?iso-8859-1?q?Borntr=E4ger?=
<[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
Followup to: <[email protected]>
By author: Urban Widmark <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On 19 Jan 2002, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Urban Widmark <[email protected]>
> 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 [email protected]
Our lives are forever changed. But *that* is exactly as it always was.