Slashdot Mirror
Open Source Distributed File Systems?
bertok asks: "I've noticed that even though most MS Windows services can be clustered to some extent, file shares can't! At first glance, DFS
seems to be the solution, but it doesn't propagate locks, so it's useless in a typical office environment for sharing documents. How have others solved this problem in the past for Microsoft-centric networks? Exchange public folders? Oracle's IFS? Third party products?" Come to think of it, it's been a while since we last asked this question. Have the 2+ years made a difference?
Thank you for pointing out times in the past in which you have previously run stories on similar topics. I wish other Slashdot "editors" would do the same instead of posting 10,000 duplicates per day. Thanks again.
You could try IBM's AFS for Windows.
Except there'a free version of AFS now, OpenAFS.
You're really better off using something like Intermezzo, or Coda.
But that's a lot of work; why not just use the traditional answer of NFS+automount+NIS.
-Jay Thomas
http://www.uiuc.edu/~jthomas2
Problems:
- People are using binary formats which doesn't allow CVS to merge them
- WinCVS user interface may be too complicated for an average user
Solutions:What about DAV and using davfs to mount things.
Setting up Apache with DAV support is pretty easy.
http://www.coda.cs.cmu.edu
Coda is a distributed file system descended from AFS2. Its particularly for things like disconnected operation for laptop users or during network outages, etc.
http://www.openafs.org
AFS is the mother of all distributed file systems. Well, maybe not the mother, but at least the big brother. AFS is not the easiest distributed file system in the whole world to set up, but it is worth every second of setup time if for nothing else than aggressive caching and excellent bandwidth utilization, IMHO.
Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
I've been using SFS for about four or five days, and so far I've been very impressed. Setting up an SFS client is easy, on Debian, just apt-get install sfs-client and you're done. On other distros and other Un*xes, grab the tarballs, compile and install. SFS uses a global namespace which is locally accessible via /sfs. In this directory, you'll initially see nothing. However, try changing directories into /sfs/sfs.fs.net:eu4cvv6wcnzscer98yn4qjpjnn9iv 6pi and be amazed. What you see in there is the SFS root of sfs.fs.net, the main distribution point of SFS. This is how you access any SFS server, by changing directories into its root. All that garbage after the colon is a cryptographic hash of the server's hostname, the server's public host key, and some other bits of data. The hash can be obtained by running 'sfskey hostid some.server.net'. Without using authentication, you'll have access to anything in any SFS root which has been publicly shared. Using authentication, you can have access to private shares on the SFS server just as if you were logged into that server and using the filesystem locally. For instance, I have /home privately shared on my main box. As a result, all of my users can have full access to their home directories from any SFS client in the world if they authenticate first.
I'm not aware of any Windows clients for SFS, but I've had access to SFS on Windows simply by sharing /sfs via Samba and mapping it to a Windows drive. Exactly the same semantics apply, just change directories in some.server.net:stuffstuffstuff and the contents of the share magically appear.
How's this one?
I need my diaper changed, too.
Novell's clustering solution maintains file locks for Win9x boxen, but cannot for WinNT and above. Novell claims this is due to changes that Microsoft made in the later operating systems that make keeping file locks impossible.
*shrug* I don't know, but that is what I was told.
By the way, he got the URL wrong too - www.fs.net (SFS), not www.sf.net (sourceforge)