Posted by: Administrator
on December 03, 2004 01:38 AM
Great piece and glad someone is calling attention to the issue. I, too, find Samba and NFS lacking and end up with a kludge approach on our network. We actually support Appletalk, IPX, IP, and related filesystems to tie everyone together. Yuck! I love Samba because it let me kick Windows out of the server room. I hate Samba because it is a copy of SMB and can be no better than the awful product it imitates.
I think a cross-platform, extensible solution is possible that could accomodate the evolving technologies needed to meet the requirements mentioned in the article. As a paradigm, though, I think each workstation should be able to act as a master and a client. I wouldn't propose changing the Coda or InterMezzo approach just adding to it the ability for a user who "owns" certain files to publish access to those files with fine grained ACLs. SSH and LDAP could be a part of such a system allowing a user to look up a valid account and issue a certificate of access to a person or group.
One of the problems with SMB is the chatty method used to keep peer systems "aware" of what is available. I think this could be solved easily through a new "publishing" protocol. A user wanting to make files available could publish their availability in a way that lets other users build a map of published shares within a certain domain. Several methods could be used to find available shares or a direct method could be used to import a share. For browsing and building up a local listing a user could send either broadcast or directed IP packets that first check to see if a host has something published, then it starts a conversation that checks for allowed authentication, access rules, directories and files available, etc. After that the person wanting to access a published share can get a certificate for each published share in their listing. Only when accessing a share would the client application request update information.
The problem or challenge of synchronizing could happen at a higher application layer. Versioning or check-in or out functions would also occur at this level.
Such a publishing protocol should be capable of passing multiple hops but also be restricted to local networks based on the users wishes. If someone wants to make certain files publicly available over the internet they don't need to use FTP or HTTP, but instead publish a share that allows discovery and access to the internet at large. For security, though, a WAN administrator could block the protocol in both directions to protect the unwitting.
And Windows users could replace their SMB clients with this new one and solve many headaches...!
Learn about Linux
Download Linux
Get Linux help
Future File Systems
Posted by: Administrator on December 03, 2004 01:38 AMI think a cross-platform, extensible solution is possible that could accomodate the evolving technologies needed to meet the requirements mentioned in the article. As a paradigm, though, I think each workstation should be able to act as a master and a client. I wouldn't propose changing the Coda or InterMezzo approach just adding to it the ability for a user who "owns" certain files to publish access to those files with fine grained ACLs. SSH and LDAP could be a part of such a system allowing a user to look up a valid account and issue a certificate of access to a person or group.
One of the problems with SMB is the chatty method used to keep peer systems "aware" of what is available. I think this could be solved easily through a new "publishing" protocol. A user wanting to make files available could publish their availability in a way that lets other users build a map of published shares within a certain domain. Several methods could be used to find available shares or a direct method could be used to import a share. For browsing and building up a local listing a user could send either broadcast or directed IP packets that first check to see if a host has something published, then it starts a conversation that checks for allowed authentication, access rules, directories and files available, etc. After that the person wanting to access a published share can get a certificate for each published share in their listing. Only when accessing a share would the client application request update information.
The problem or challenge of synchronizing could happen at a higher application layer. Versioning or check-in or out functions would also occur at this level.
Such a publishing protocol should be capable of passing multiple hops but also be restricted to local networks based on the users wishes. If someone wants to make certain files publicly available over the internet they don't need to use FTP or HTTP, but instead publish a share that allows discovery and access to the internet at large. For security, though, a WAN administrator could block the protocol in both directions to protect the unwitting.
And Windows users could replace their SMB clients with this new one and solve many headaches...!
#