[nycbug-talk] glusterfs

[Miles Nordin]

>>>>> "pw" == Pete Wright <pete at nomadlogic.org> writes:

    pw> another gfs worth taking a look at is hadoop:
    pw> http://hadoop.apache.org/core/
    pw> It is a google-filesystem workalop

GFS from redhat != GFS from google.

The first one is a POSIX filesystem.

The second one and hadoop are neither one of them POSIX filesystems.
They are more like crappy databases in that the interface to them is a
library with its own unique API.  and unlike a database which can
efficiently store smaller structured objects than a filesystem can, I
think maybe you can only store really big files in hadoop/google-gfs,
not small ones and maybe not randomly-accessed ones.  Lustre,
GlusterFS, RedHat GFS, all purport to accomodate small files, and also
big files which must be randomly-accessed (like .vdi/.vmdk).

And Celeste sounds insane.  If they would manage to make the old
Berkeley filesystem from 2002 on which it's based actually work and
nothing else, it could be awesome, but they are trying to deliver a
Platform again (platform == $$$, software == $).  I think it'll be
strangled by necktie damage.  Every other ``platform'' Sun has
delivered seems to be cumbersome, brittle, slow, stagnant, and behind
schedule.  I think they should not try to deliver the platform and its
fundamental building blocks in one step---all the stuff they have now
which doesn't suck is delivered seperably.  

It looks like so far yuo get at least some of the source:

 http://src.opensolaris.org/source/xref/celeste/trunk/

also it sounds like delivers the snapshot feature I wanted and then
some.

Maybe these distributed filesystems will categorize themselves across
which ones are optimized for high-latency networks, and which for
maximum throughput on low-latency preferably-lossless networks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 304 bytes
Desc: not available
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20090504/45ef54c4/attachment.bin>