[nycbug-talk] glusterfs
Pete Wright
pete at nomadlogic.org
Mon May 4 14:44:37 EDT 2009
On 4-May-09, at 11:05 AM, Miles Nordin wrote:
>>>>>> "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.
>
yes...i was using gfs in two separate ways which were unclear:
Global FileSystem < -- generic
Google FileSystem < -- mostly referring to paper google released
several years ago
and gfs from rh sucks...gfs2 from rh is getting there but i wouldn't
want anyone to go there either...
> 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).
>
well i think that's the whole point, and one which is made in the
"google paper". it's not a filesystem that most people think of it -
it is more of a way to store large, arbitrary data sets that are not
suited to RDBMS's. i think when people start going down the global
filesystem route they are not going to be using them on a single node
- but are using them to store *lots* of arbitrary data that will be
getting accessed by *many* consumers. the side benefits being that it
scales very well compared to a POSIX fs, gives you some level of
redundancy for "free" and has a programatic API that is used to access/
monitor/manage data. all of which become a real concern when you
start dealing with PB's worth of online data.
don't forget OCFS too :)
i'd personally never use a global filesystem for OS images or things
of that nature. use a proper SAN or device than export LUNs to your
hyper visor as proper block devices (via either FCP, iSCSI, AoE etc)
and be done with it. no need to incur the complexity of a global
filesystem when all you really want is block level disk access.
-p
More information about the talk
mailing list