SMB filesystem

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

Hi,

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

On Sun, Jun 02, 2002 at 11:00:13PM +0200, Jean-Eric Cuendet wrote:
...

Look at how CODA, and especially Intermezzo do it.

/Matti Aarnio

[...]

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

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

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.

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/

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"