Erlang filesystem (a bit long) (was: Re: File versioning)

[Chris Pressey]

What, no takers for #2?  I'm disappointed in you guys :)

On 08 May 2003 06:05:05 +0200
Luke Gorrie <luke@REDACTED> wrote:
> You can do this with my Erlang NFS server. It's a quick hack, very
> non-robust and unfeatureful etc. It's in the Jungerl if you want to
> play around - lib/enfs/.

And Scott wrote:
> ... we did such a thing.  It used TCP (and UNIX domain sockets, later)
> and Sun RPC.  Client applications spoke RPC to an Erlang I/O daemon
> (running on the same box).  The Erlang I/O daemon "knew" were files
> were really stored: their "real" path(s) on an NFS server(s)
> somewhere. [...] We even stole flock(2) and implemented a leasing
> scheme that was *reliable* when talking to an NFSv3 file server.  Heh.

As cool as both of these sound, well... to paraphrase Bengt -

I could be blinded by the thousands of horror stories and the
unfortunate nickname "Network Failure System" given to it by a guru I
highly respect, but I believe that sticking your data on 8" floppy disks
and walking it from one computer to the other is superior to NFS in
every way :)

OK, I'm a *little* biased.  I haven't used it in ages, apparently NFSv4
has reliable locking semantics, etc.  But still I have the vague feeling
it's not quite what I'm looking for - I'd rather have a replicated file
system, like an "auto-mirror" perhaps, that propogates updates exactly
when it needs to.

That doesn't mean, of course, that I won't look into enfs; producing a
mountable filesystem from Erlang doesn't have anything inherently to do
with NFS, and it would be the most seamless way to go (and just plain
cool besides.)  But it too has the drawback that porting it outside of
Unix would probably be a royal pain.

(For this reason, for #3 to be portable, shell scripts, tcpcat, and
unix-domain sockets are out; Perl + inet sockets looks like a better
choice - maybe C if startup-time is critical (The Erlang runtime's
relatively long startup-time is what started me thinking about this
approach in the first place.))

#3 also doesn't have anything inherently to do with NFS or any other
filesystem; what would be most useful would be a 'tellerl' command that
simply sends a message (+ input data) to the Erlang node and waits for
a response (+ output data.)  Sort of an RPC-like mechanism, except of
course it's probably more productive to think of it in terms of
messages rather than procedure calls.  'erlfsstore' et al could be built
on top of 'tellerl'.

There is also at least one other option I missed:

#4 - have the Erlang node watch the OS's filesystem and react to changes
     in it.

Different operating systems do this differently, though - FreeBSD has
kqueues, WinNT has a notification service, and I don't know what Linux
has - so while this approach has a certain elegance, it too would be
difficult to make portable, unless it resorted to polling on unknown
OS'es, which would seriously detract from the elegance.

This too would be a nifty thing to have outside of the context of having
it implement a filesystem.

Speaking of kqueues - I searched the archives and about a year ago, Per
announced a 'devpoll' patch which employed them - but it seems like it
was more for the purposes of getting better performance from sockets &
other files, than for the purposes of watching and reacting to the
filesystem.

Which brings me to ask if anyone has interfaced Erlang with kqueue in a
general fashion, for example as a port from which you can receive
messages when kevents happen.  And/or the same concept for other
operating systems.

This is definately beyond my fu but in a pinch I could probably put
together something that uses os:cmd("wait_on " ++ ...).  (Not as
efficient to shell an executable, certainly, but still far more
efficient than polling :)

-Chris