This is really cool! One section of our application is mapping, which uses <a href="http://mapserver.gis.umn.edu/">MapServer</a> along with <a href="http://ka-map.maptools.org/">ka-map</a>. For tiles & shape files, we have an NFS backend (a bigass NetApp box) to serve all of these up. Granted, the netapp performs really well, and serving up static tiles seems to be an easy task for it at the moment. If this particular service becomes really popular, I could see that a large cache could be helpful to our architecture.
<br><br>I would definitely be excited if someone started working on this. (I might even help out if I can!)<br><br>--Cal<br><br>-- <br>Cal Heldenbrand<br> FBS Data Systems<br> E-mail: <a href="mailto:cal@fbsdata.com">
cal@fbsdata.com</a>
<br><br><div><span class="gmail_quote">On 5/9/07, <b class="gmail_sendername">Erik Osterman</b> <<a href="mailto:e@osterman.com">e@osterman.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
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." <br>
<br>
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. <br>
<br>
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.<br>
<br>
<br>
Thanks for the suggestion...<br>
<br>
Erik Osterman<br>
<br>
Bruce Wang wrote:
<blockquote cite="http://mid8d581cfd0705082357n47247ab2g11373d11f3a06904@mail.gmail.com" type="cite"><br>
<br>
<div><span class="q"><span class="gmail_quote">On 5/9/07, <b class="gmail_sendername">Erik
Osterman</b> <<a href="mailto:e@osterman.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">e@osterman.com</a>>
wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">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 :)</div>
</blockquote>
</span><div><br>
<a href="http://danga.com/mogilefs/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://danga.com/mogilefs/</a> <br>
</div>
<br>
Is this what you want? Also by <a href="http://bradfitz.com/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Brad
Fitzpatrick
</a><br>
<br>
<br>
</div>
<br>
<br clear="all">
<br>
-- <br>
simple is good<br>
<a href="http://brucewang.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://brucewang.net</a><br>
skype: number5
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><br><br>