Hi Ian!<div><br></div><div>You see, there isn&#39;t much why we shouldn&#39;t do it! There is the Google folks and Hadoop folks having this kind of efficiency and we dont! With 100 storages you can have N+5 redundancy and still be 94,7% IO efficient, considering the big clusters out there.</div>

<div><br></div><div>Having that at GlusterFS would mean a stable high performance filesystem getting much more efficient.</div><div><br></div><div>Best!</div><div><br><div class="gmail_quote">On Tue, Nov 22, 2011 at 4:25 AM, Ian Latter <span dir="ltr">&lt;<a href="mailto:ian.latter@midnightcode.org">ian.latter@midnightcode.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<br>
<br>
<br>
  I think what you&#39;re describing is functionally equivalent<br>
to the Google File System;<br>
    <a href="http://labs.google.com/papers/gfs.html" target="_blank">http://labs.google.com/papers/gfs.html</a><br>
    <a href="http://en.wikipedia.org/wiki/Google_File_System" target="_blank">http://en.wikipedia.org/wiki/Google_File_System</a><br>
<br>
  And, by comparable design, Hadoop File System;<br>
<br>
<a href="http://hadoop.apache.org/common/docs/r0.20.0/hdfs_design.html" target="_blank">http://hadoop.apache.org/common/docs/r0.20.0/hdfs_design.html</a><br>
<br>
  Google/Hadoop FS framed a set of principles that I<br>
(and a friend of mine - Michael Welton) were hoping to<br>
achieve by moving to GlusterFS - and I think it will still<br>
get us all the way there once we get IPSEC underneath<br>
it and it deals with WANs better.<br>
<br>
  In that context, I&#39;m a fan already :)<br>
<br>
  However, I would like to add that if you&#39;re going to go<br>
to the trouble of providing a hashed-block abstraction<br>
layer, that you make it pluggable.  I.e.  before I was taken<br>
ill in September 2009 I was looking at implementing a<br>
de-dupe block for GlusterFS.  Another friend (Chris<br>
Kelada) and I came up with a full de-dupe model one<br>
evening which I thought was quite simple.  What stalled<br>
me before I fell ill was an issue with descriptors that may<br>
have been fixed during the BSD porting activity that I saw<br>
on this list a week or two ago.<br>
  De-dupe needs a hash for a chunk of data.  What we<br>
proposed was an arbitrary sized chunk (say 1Mbyte)<br>
hashed, then stored in the underlying layer via its hash -<br>
i.e. if my block hashed to &quot;thisismyhash&quot; then it would be<br>
stored in /.dedupe/thi/sis/myh/ash/data.bin with provision<br>
for an index to allow multiple blocks of the same hash to<br>
co-exist at the same location (i.e. either n x chunk_size<br>
offset into the data file, or n data files).<br>
<br>
  This would have a high read/write performance penalty<br>
(lots of iops in the underlying layer per iop in the de-dupe<br>
layer) but it reaps the obvious space benefit.<br>
<br>
  Thus if a data hashing block were to be forged, its re-<br>
application could be quite broad - but only if considered<br>
beforehand; then I&#39;d be all for it.<br>
<br>
<br>
<br>
Cheers,<br>
<div class="im"><br>
<br>
----- Original Message -----<br>
&gt;From: &quot;Daniel van Ham Colchete&quot; &lt;<a href="mailto:daniel.colchete@gmail.com">daniel.colchete@gmail.com</a>&gt;<br>
</div><div><div class="h5">&gt;To: &quot;glusterfs&quot; &lt;<a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a>&gt;<br>
&gt;Subject:  [Gluster-devel] DHT-based Replication<br>
&gt;Date: Mon, 21 Nov 2011 21:34:30 -0200<br>
&gt;<br>
&gt; Good day everyone!<br>
&gt;<br>
&gt; It is a pleasure for me to write to this list again, after<br>
so many years. I<br>
&gt; tested GlusterFS a lot about four years ago because of a<br>
project I still<br>
&gt; have today. It was 2007 and I worked with Gluster 1.2 and<br>
1.3. I like to<br>
&gt; think that I gave one or two good ideas that were used in<br>
the project. Amar<br>
&gt; was a great friend back then (friend is the correct word<br>
as he was on my<br>
&gt; Orkut&#39;s friends list). Unfortunately Gluster&#39;s performance<br>
wasn&#39;t good<br>
&gt; enough, mostly because of the ASCII protocol and I had to<br>
go to the HA-NFS<br>
&gt; way.<br>
&gt;<br>
&gt; By that time, a new clustering translator was created, it<br>
was called DHT.<br>
&gt; In those four years that passed I studied DHT and even<br>
implemented a<br>
&gt; DHT-based internal system here at my company to create a<br>
PostgreSQL cluster<br>
&gt; (I didn&#39;t do any reconciliation thing though, that is the<br>
hard part for<br>
&gt; me). It worked fine, it still does!<br>
&gt;<br>
&gt; What is the beauty of DHT? It is easy to find where a file<br>
or a directory<br>
&gt; is in the cluster. It is just a hash operation! You just<br>
create a cluster<br>
&gt; of N servers and everything should be distributed evenly<br>
through them.<br>
&gt; Every player out there got the distribution part of<br>
storage clusters right:<br>
&gt; GlusterFS, Cassandra, MongoDB, etc.<br>
&gt;<br>
&gt; What is not right in my opinion is how everybody does<br>
replication.<br>
&gt; Everything works in pairs (or triples, or replica sets of<br>
any number). The<br>
&gt; problem with pairs (and replica sets) is that in a 10<br>
server cluster, if<br>
&gt; one fails only its pair will have to handle the double of<br>
the usual load,<br>
&gt; while the other ones will be working with the usual load.<br>
So we can assign<br>
&gt; at most 50% of its capacity to any storage server. Only<br>
50%. 50% efficiency<br>
&gt; means we spend the double in hardware, rack space and<br>
energy (the worst<br>
&gt; part). Even with RAID10 storage, the ones we use, have<br>
this problem too. If<br>
&gt; a disk dies, one will get double read IOs while the other<br>
ones are 50% idle<br>
&gt; (or should be).<br>
&gt;<br>
&gt; So, I have a suggestion that fixes this problem. I call it<br>
DHT-based<br>
&gt; replication. It is different from DHT-based distribution.<br>
I already<br>
&gt; implemented it internally, it already worked, at least<br>
here. Giving the<br>
&gt; amount of money and energy this idea saves, I think this<br>
idea is worth a<br>
&gt; million bucks (on your hands at least). Even though it is<br>
really simple.<br>
&gt; I&#39;m giving it to you guys for free. Just please give<br>
credit if you are<br>
&gt; going to use it.<br>
&gt;<br>
&gt; It is very simple: hash(name) to locate the primary server<br>
(as usual), and<br>
&gt; use another hash, like hash(name + &quot;#copy2&quot;) for the<br>
second copy and so on.<br>
&gt; You just have to certify that it doesn&#39;t fall into the<br>
same server, but<br>
&gt; this is easy: hash(name + &quot;#copy2/try2&quot;).<br>
&gt;<br>
&gt; So, say we have 11 storage servers. Yeah, now we can have<br>
a prime number of<br>
&gt; servers and everything will still work fine. Imagine that<br>
storage server<br>
&gt; #11 dies. The secondary copy of all files at #11 are<br>
spread across all the<br>
&gt; other 10 servers, so those servers are now only getting a<br>
load 10% bigger!<br>
&gt; Wow! Now I can use 90% of what my storages can handle and<br>
still be up when<br>
&gt; one fails! Had I done this the way things are today, my<br>
system would be<br>
&gt; down because there is no way a storage can handle 180% of<br>
IO its capacity<br>
&gt; (by definition). So now I have 90% efficiency! For exactly<br>
the same costs<br>
&gt; to have 50k users I can have 90k users now! That is a 45%<br>
costs savings on<br>
&gt; storage, with just a simple algorithm change.<br>
&gt;<br>
&gt; So, what are your thoughts on the idea?<br>
&gt;<br>
&gt; Thank you very much!<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Daniel Colchete<br>
</div></div>&gt; _______________________________________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
&gt; <a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
&gt;<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Ian Latter<br>
Late night coder ..<br>
<a href="http://midnightcode.org/" target="_blank">http://midnightcode.org/</a><br>
</font></span></blockquote></div><br></div>