e at osterman.com
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...
Bruce Wang wrote:
> On 5/9/07, *Erik Osterman* <e at osterman.com <mailto:e at osterman.com>>
> 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 <http://bradfitz.com/>
> simple is good
> skype: number5
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached