Erik Osterman e at
Wed May 9 07:28:39 UTC 2007

MogileFS is pretty sweet; I'll give it that. We considered it pretty 
seriously before going with GlusterFS. Since MogileFS relies on 
application modifications, which isn't a possibility when the 
application is blackbox, we ultimately decided against it. I don't think 
they finished the fuse module either, and the web page still says, 
"We've prototyped a FUSE binding, so you could use MogileFS without 
application support, but it's not production-ready."

Also, I'm less thrilled about managing MogileFS with all of its Perl 
depenencies. Memcache and GlusterFS are a cakewalk in comparison to 
setup and configure. Granted, GlusterFS isn't yet fully production 
worthy, it's been stable for us.

Note that CacheFS is not dependent on the underlying filesystem, so a 
MemcacheFS developed in the same fashion could straddle multiple 
exported filesystem types, such as NFS, GlusterFS, SMB, OpenAFS, and 
even MogileFS. In much the same way Memcache doesn't tie you to one 
database, MemcacheFS wouldn't tie you to one type of networked filesystem.

Thanks for the suggestion...

Erik Osterman

Bruce Wang wrote:
> On 5/9/07, *Erik Osterman* <e at <mailto:e at>> 
> wrote:
>     Right, this is along the same lines, but not generalized. They
>     made Lighty Memcache aware, but that doesn't do much for other
>     applications, e.g. our XSLT processor which can only access files.
>     Further more, since it's not generalized, the cached data cannot
>     easily be shared by many unrelated applications. So, if different
>     applications employ their own Memcache caching strategy, a lot of
>     memory is waisted on duplicate data. Though, embracing this idea,
>     one could use Lighty + modmemcache + webdav + fuse but that sounds
>     very slow :)
> Is this what you want? Also by Brad Fitzpatrick <>
> -- 
> simple is good
> skype: number5 

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the memcached mailing list