SMB filesystem

SMB filesystem

[Jean-Eric Cuendet]

Hi,
Actually, SMB access with Linux is done in the way:
- Mount a share
- Access it with rights defined at mount time.

I'm thinking of implementing an smb filesystem, the way AFS implement 
the AFS client fs kernel driver.
- Mount the smb filesystem on /smb (done at boot time)
- Every user has list dir access on /smb
- There, you see each workgroup/domain available on the network
- Then in each domain, a list of machines
- Then in each machine, a list of shares
- Then a list of files/dirs
Access will be granted using the SMB token (like a kerberos ticket) 
issued by the primary domain controller.
It's the way the windows explorer works. It's cool and useful.

What do you think of implementing it that way? Comments?

I'd like to implement it with libsmbclient.so, a samba provided lib that 
let you have access to workgroups/machines/shares in a MS network from 
Linux (or UNIX).
Then, it can't be kernel only. I need a userspace daemon with which the 
kernel will communicate, since the shared lib can't be added to the kernel.
How do you think is the best way of doing things?
Making a minimal FS kernel driver that communicate with a complex 
userspace daemon?

Is it possible to implement a userspace filesystem? In which way?
Is there a generic interface in the kernel for userspace implemented 
filesystems?
Where is the doc on that?

Thanks for comments/ideas.
-jec

Re: SMB filesystem

[Thunder from the hill]

Hi,

On Sun, 2 Jun 2002, Jean-Eric Cuendet wrote:
> [blah]
> How do you think is the best way of doing things?
> Making a minimal FS kernel driver that communicate with a complex 
> userspace daemon?

Virtual loop device? Have an userspace daemon feed it into a loop device, 
and make the kernel mount that. Just suggesting...

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: SMB filesystem

[Matti Aarnio]

On Sun, Jun 02, 2002 at 11:00:13PM +0200, Jean-Eric Cuendet wrote:
...
> Then, it can't be kernel only. I need a userspace daemon with which the 
> kernel will communicate, since the shared lib can't be added to the kernel.
> How do you think is the best way of doing things?
> Making a minimal FS kernel driver that communicate with a complex 
> userspace daemon?

  Look at how  CODA,  and especially Intermezzo do it.

> Thanks for comments/ideas.
> -jec

/Matti Aarnio

Re: SMB filesystem

[Marius Gedminas]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Sun, Jun 02, 2002 at 11:00:13PM +0200, Jean-Eric Cuendet wrote:
> I'm thinking of implementing an smb filesystem, the way AFS implement 
> the AFS client fs kernel driver.
> - Mount the smb filesystem on /smb (done at boot time)
> - Every user has list dir access on /smb
> - There, you see each workgroup/domain available on the network
> - Then in each domain, a list of machines
> - Then in each machine, a list of shares
> - Then a list of files/dirs
[...]
> Thanks for comments/ideas.

Can this be done with autofs in userspace?  It works for NFS, just cd to
/autofs-mountpoint/hostname.

Marius Gedminas
-- 
Any sufficiently advanced Operating System is indistinguishable from Linux.
		-- Jim Dennis

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: SMB filesystem

[Urban Widmark]

On Sun, 2 Jun 2002, Jean-Eric Cuendet wrote:

> What do you think of implementing it that way? Comments?

I would do the browsing as one part and the smb file access as another.
That could allow a user to choose browsing implementation and file access
implementation independently. On the network level they have "nothing" in
common.

For info on user-space filesystems you should spend some more time with
google. There are people out there that have done that.


The browsing can be done as an add-on to autofs (in some form) or as a
userspace filesystem of its own.

Currently autofs has a problem where it won't show the mountpoints of
non-mounted directories, but I think you would run into that problem too.
(short version of the problem: how do you prevent 'ls -l' from mounting
 all filesystems in a directory?)

/Urban

Re: SMB filesystem

[Marius Gedminas]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Sun, Jun 02, 2002 at 11:34:59PM +0200, Urban Widmark wrote:
> Currently autofs has a problem where it won't show the mountpoints of
> non-mounted directories, but I think you would run into that problem too.
> (short version of the problem: how do you prevent 'ls -l' from mounting
>  all filesystems in a directory?)

It would be nice to have this fixed, that is, to allow listing of
potential mountpoints, and ignore stat() on them instead of trying to
mount immediately.

BTW that's the only remaining feature that makes supermount more
"user-friendly" than autofs for floppies/CD-ROMs.

Marius Gedminas
-- 
... there is always a well-known solution to every human problem -- neat,
plausible, and wrong.
		-- H. L. Mencken (1880-1956), "Prejudices"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: SMB filesystem

[Ion Badulescu]

On Sun, 2 Jun 2002 23:34:59 +0200 (CEST), Urban Widmark <urban@teststation.com> wrote:

> Currently autofs has a problem where it won't show the mountpoints of
> non-mounted directories, but I think you would run into that problem too.
> (short version of the problem: how do you prevent 'ls -l' from mounting
> all filesystems in a directory?)

You add the concept of a "light" lookup, and you make path_walk() call this
"light" lookup (be that a separate fs method, or a flag passed down to real
lookup()) iff the path component being looked up is the last component in 
the path. A "light" lookup sets a flag in the inode signalling that the inode
is incomplete, so cached_lookup() can check this flag and call a "full"
lookup() (or perhaps a "full" revalidate()) if necessary.

The actual details need to be thought out a bit more, this is only a general
outline. In particular, we need a bullet-proof way to determine when to
"upgrade" the inode from "light" to "full".

You then also need to add a "getdents" kind of message to the autofs 
protocol, and a "light lookup" message (which confirms the existence of the
entry, and maybe returns the type of the entry: symlink or directory).

Once all this is done, I'll add support for it in am-utils in a jiffy...

Ion (am-utils co-maintainer)

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: intent-based lookups (was Re: SMB filesystem)

[Andreas Dilger]

On Jun 03, 2002  18:45 -0400, Ion Badulescu wrote:
> On Sun, 2 Jun 2002 23:34:59 +0200 (CEST), Urban Widmark <urban@teststation.com> wrote:
> 
> > Currently autofs has a problem where it won't show the mountpoints of
> > non-mounted directories, but I think you would run into that problem too.
> > (short version of the problem: how do you prevent 'ls -l' from mounting
> > all filesystems in a directory?)
> 
> You add the concept of a "light" lookup, and you make path_walk() call this
> "light" lookup (be that a separate fs method, or a flag passed down to real
> lookup()) iff the path component being looked up is the last component in 
> the path. A "light" lookup sets a flag in the inode signalling that the inode
> is incomplete, so cached_lookup() can check this flag and call a "full"
> lookup() (or perhaps a "full" revalidate()) if necessary.
> 
> The actual details need to be thought out a bit more, this is only a general
> outline. In particular, we need a bullet-proof way to determine when to
> "upgrade" the inode from "light" to "full".

This may fit nicely with some work we are doing for Lustre (a scalable
distributed filesystem for Linux) which needs to do "intent-based
lookups".  It has a similar desire to separate the lookups of the start
of the path from the lookup of the last component of the path.  Peter
Braam (CC'd) has a patch for 2.4.18 which implements this.  I pass the
discussion over to him...

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/