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?

Dear Cliff

[Anonymous Coward]

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.

So Windows show its VMS roots again

[Pauly]

You could try IBM's AFS for Windows [ibm.com].

Same answers as before

[jthomas2]

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

Re:Same answers as before

[Raleel]

But are intermezzo or coda really ready to go? I have no experience with them myself, but was recently asked this same question

Different answer

[qeL3-i]

Why not try something different? Like install a CVS server and give everybody WinCVS and other clients like good old command-line cvs to connect to it. Then all your important documents are in one place so you can easily back them up. You have logs so that you can see who made changes and when.

Problems:

1. People are using binary formats which doesn't allow CVS to merge them
2. WinCVS user interface may be too complicated for an average user

Solutions:

1. Change to a text format
2. Training, or simplify the interface

Re:Same answers as before

[Ashurbanipal]

why not just use the traditional answer of NFS+automount+NIS?

Because NFS has to be constantly patched (weekly if you are using HP-UX) to make it have some semblance of stability, reliability, or security.

Because NIS is inherently subject to denial of service.

Because every automounter I ever used was bug-riddled (again, exceptionally so in that monstrosity HP-UX; version 11.00 shipped two automounters which were both buggy). I understand Sun's stuff is better, but I don't use it so I wouldn't know.

..and finally, because a half-assed solution doesn't become adequate just by becoming a de-facto standard.

Re:Same answers as before

[Ashurbanipal]

Heh. Sadly, I have to admin several humongeous HP-UX boxes. Vendors of turn-key systems love HP-UX because it rarely changes in any significant way; they can concentrate on adding features to their products instead of trying to keep up with improvements in the underlying operating system. Big improvements in an OS frequently break applications - ask the people who try to keep up with Microsoft, for example, or linux (wait, I just finished porting to IPchains and now I gotta do IPtables? Wah!).

I'm not kidding when I say there are patches to HP's NFS just about weekly. Sometimes they hit four or five bugs in a single week, so they can wait a week for the next ONC/NFS Cumulative Patch Release.

The best thing about HP-UX is the Veritas file system, which (obviously) HP is in no way responsible for. Other than that it's an incredibly weak and old-fashioned OS (list your favorite bug - how about the way the standard backup utilities corrupt and/or delete their lame implementation of ACLs?). That HP/Compaq is discontinuing DEC's unix for this crap is a sad commentary on their business model.

Gotta go now, HP-UX's NFS just suddenly decided all its (already mounted) volumes are read-only and the users are freaking out.

What about DAV?

[Karora]

What about DAV and using davfs to mount things.

Setting up Apache with DAV support is pretty easy.

Lots of options

[nadador]

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.

Re:Lots of options

[WetCat]

I tried CODA - it's a pure crap. It doesn't work as promised.

Self-Certifying File System (SFS)

[Anonymous Coward]

I've been using SFS [sf.net] 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.

Re:Self-Certifying File System (SFS)

[dirtyhippie]

SFS has some problems. Considering that last time I checked, you needed to install a custom version os such utils as ls if you wanted SFS to even have the user/groupIDs on remote systems display as non-gibberish. Second, SFS is SLOW AS MOLASSES. Way slower than NFS, SMB, or SFTP. We're talking orders-of-magnitude slower. And you can forget about flock, because SFS uses a weird NFS-to-localhost thing anyway, which is what this guy wanted to begin with.

PS - Wrong URL too

[dirtyhippie]

By the way, he got the URL wrong too - www.fs.net (SFS) [fs.net], not www.sf.net (sourceforge) [sf.net]