Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source Distributed File Systems?

Posted by Cliff on from the if-you-can-do-it-for-webservers... dept.

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?

3 of 23 comments (clear)

  1. Same answers as before by jthomas2 · · Score: 2, Informative

    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

  2. Lots of options by nadador · · Score: 3, Informative

    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.
  3. Self-Certifying File System (SFS) by Anonymous Coward · · Score: 3, Informative

    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.