login
Search
Nir Tzachar recently announced the availability of a new filesystem referred to as srFS, or the "Self-Stabilizing Replication File System". According to the project's home page:
"srFS is a global file system designed to be distributed geographicly over multiple locations and provide a consistent, high available and durable infrastructure for information."
Among the available publications about srFS, an implementation report [pdf] describes a self stabilizing system as "a system that can automatically recover following the occurrence of (transient) faults. The idea is to design a system which can be started in an arbitrary state and still converge to a desired bahavior." The project is divided into two components, a kernel module for the stable 2.4 kernel, and a user-space caching daemon written in Java, communicating with each other via a character device. Nir's full announcement email follows.
From: Nir Tzachar [email blocked] To: linux-fsdevel Subject: srfs - a new file system. Date: Mon, 20 Oct 2003 11:12:07 +0200 (IST) hello all. We're proud to announce the availability of a _proof of concept_ file system, called srfs. ( http://www.cs.bgu.ac.il/~srfs/ ). a quick overview: [from the home page] srfs is a global file system designed to be distributed geographicly over multiple locations and provide a consistent, high available and durable infrastructure for information. Started as a research project into file systems and self-stabilization in Ben Gurion University of the Negev Department of Computer Science, the project aims to integrate self-stabilization methods and algorithms into the file (and operation) systems to provide a system with a desired behavior in the presence of transient faults. Based on layered self-stabilizing algorithms, provide a tree replication structure based on auto-discovery of servers using local and global IP multicasting. The tree structure is providing the command and timing infrastructure required for a distributed file system. The project is basically divided into two components: 1) a kernel module, which provides the low level functionality, and disk management. 2) a user space caching daemon, which provide the stabilization and replication properties of the file system. these two components communicate via a character device. more info on the system architecture can be find on the web page, and here: http://www.cs.bgu.ac.il/~tzachar/srfs.pdf We hope some will find this interesting enough to take for a test drive, and wont mind the latencies ( currently, the caching daemon is a bit slow. hopefully, we will improve it in the future. ) anyway, please keep in mind this is a very early version that only works, and keeps the stabilization properties. no posix compliance whatsoever... the code contains several hacks and design flaws that we're aware of, and probably many that we're not... so please be gentle ;) if someone found this interesting, please contact us with ur insights. cheers, the srfs team. p.s I would like to thank all members of this mailing list (fsdevel), for ur continual help with problems we encountered during the development. thanks guys (and girls???). ======================================================================== nir.
From: Eric Sandall [email blocked] Subject: Re: srfs - a new file system. Date: Mon, 20 Oct 2003 14:00:38 -0700 This sounds fairly similar to Coda[0], which is already in development and use. -sandalle [0] http://www.coda.cs.cmu.edu/ -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o? K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++) tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+ ------END GEEK CODE BLOCK------ Eric Sandall | Source Mage GNU/Linux Developer [email blocked] | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
From: Nir Tzachar [email blocked] Subject: Re: srfs - a new file system. Date: Tue, 21 Oct 2003 14:07:04 +0200 (IST) > > This sounds fairly similar to Coda[0], which is already in development and use. > not at all. coda is not self stabilizing at all. srfs is also a totally distributed file system -> see the doc. bye ======================================================================== nir.
Ultracool!
Is this kind of a NFS over Bittorrent? (forgive me, I like this stuff, but understand nada, zero, niente...)
Java?
With a programming language like Java, how can you hope to have an efficient system?
Java?!
They use java???????? If so, welcome to /dev/null srfs.
can't agree more...
I guess for prototyping, if you must. java's implementation and runtime is just wrong on way too many levels to be really usable.
I don't want to knock a specific language, and am a firm believer in the "no pet languages allowed" motto. But I've just had one too many bad experiences with java('s implementation), and would definately think it's way inappropriate for code at such a low level.
why java
> With a programming language like Java, how can you hope to have an
efficient system?
well, in essence, ur right.
we used java since development in this language is more rapid than c.
we plan to implement the daemon in c, when the system will be more stable.
Well, I'll wait for that time
Well, I'll wait for that time to come.
okay for prototype
They use java for their "proof of concept"; this may actaully be a good thing, because by the time they come to write a C version, they won't make the same design mistakes and the design will be cleaner.
Java
Yes, when you decide to throw out the Java one, that probably is fast enough and reliable enough for 99% of the cases, and rewrite it in C, adding in accidental buffer overflows, and potential remote exploits, it will be much better. Instead, why not just optimize the Java one and ship it with a nice secure java.policy file?
Re: Java
Maybe when Java becomes portable. Where's the JRE for the m68k? A stable implementation for Alpha? Or even the latest standard *not* from Sun?
"Java" (as most people use it for "enterprise" systems) is portable like the Win32 API is portable. Its available in its full complement on x86 Linux, x86 Windows and SPARC Solaris (and possibly PowerPC AIX and x86 FreeBSD, if you're stay behind a few versions). Win32/WINE runs reliably on about the same.
And of course, there are like a gazillion differet degrees of Java. J2EE .0, .1, .2, .3, .4, .5. Etc, etc, etc. As opposed to C, where you have ISO C, SuSv3, and GNU/Linux, three complementary levels of C interfaces. Stable, dependable, reliable and open.
There's a reason why the Solaris developers revolted and refused to write their system utilities in Java. The only thing that will save Java as a FOSS language is possibly Parrot (Perl6 VM) or GCJ.
Re: Java
>There's a reason why the Solaris developers revolted and refused to write their system utilities in Java.
Unfortunately, they didn't won totally, the system management console in Solaris9 (smc) is written in Java :-(
The result?
smc is sllllllloooooooowwww (on modern HW: Sunblade150 with 1GB of RAM)!
(my life)
Before on Solaris8, I used a GUI to define the disk's mirroring (metatool), the interface was strange, ugly but very usefull once you learned it, smc is a pig and it's interface is not functionnal at all!!
The result? I learned the command-line tools and don't use smc.
I've been badly burned by Java in 98-99, and apparently for GUI it haven't improved much since..
this vs. Inter-mezzo?
Aside from the implemenation details being different, what makes this project's end result different than what is being done with Inter-Mezzo?
I'm not asking this as a rhetorical question or to start a flame war, but there is probably something I'm missing; I'm just looking for clarification.