<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 10:39 PM, Gandalf Corvotempesta <span dir="ltr">&lt;<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-05-01 18:57 GMT+02:00 Pranith Kumar Karampuri &lt;<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>&gt;:<br>
&gt; Yes this is precisely what all the other SDS with metadata servers kind of<br>
&gt; do. They kind of keep a map of on what all servers a particular file/blob is<br>
&gt; stored in a metadata server.<br>
<br>
</span>Not exactly. Other SDS has some servers dedicated to metadata and,<br>
personally, I don&#39;t like that approach.<br>
<span class=""><br>
&gt; GlusterFS doesn&#39;t do that. In GlusterFS what<br>
&gt; bricks need to be replicated is always given and distribute layer on top of<br>
&gt; these replication layer will do the job of distributing and fetching the<br>
&gt; data. Because replication happens at a brick level and not at a file level<br>
&gt; and distribute happens on top of replication and not at file level. There<br>
&gt; isn&#39;t too much metadata that needs to be stored per file. Hence no need for<br>
&gt; separate metadata servers.<br>
<br>
</span>And this is great, that&#39;s why i&#39;m talking about embedding a sort of database<br>
to be stored on all nodes. no metadata servers, only a mapping between files<br>
and servers.<br>
<span class=""><br>
&gt; If you know path of the file, you can always know where the file is stored<br>
&gt; using pathinfo:<br>
&gt; Method-2 in the following link:<br>
&gt; <a href="https://gluster.readthedocs.io/en/latest/Troubleshooting/gfid-to-path/" rel="noreferrer" target="_blank">https://gluster.readthedocs.<wbr>io/en/latest/Troubleshooting/<wbr>gfid-to-path/</a><br>
&gt;<br>
&gt; You don&#39;t need any db.<br>
<br>
</span>For the current gluster yes.<br>
I&#39;m talking about a different thing.<br>
<br>
In a RAID, you have data stored somewhere on the array, with metadata<br>
defining how this data should<br>
be wrote or read. obviously, raid metadata must be stored in a fixed<br>
position, or you won&#39;t be able to read<br>
that.<br>
<br>
Something similiar could be added in gluster (i don&#39;t know if it would<br>
be hard): you store a file mapping in a fixed<br>
position in gluster, then all gluster clients will be able to know<br>
where a file is by looking at this &quot;metadata&quot; stored in<br>
the fixed position.<br>
<br>
Like &quot;.gluster&quot; directory. Gluster is using some &quot;internal&quot;<br>
directories for internal operations (&quot;.shards&quot;, &quot;.gluster&quot;, &quot;.trash&quot;)<br>
A &quot;.metadata&quot; with file mapping would be hard to add ?<br>
<span class=""><br>
&gt; Basically what you want, if I understood correctly is:<br>
&gt; If we add a 3rd node with just one disk, the data should automatically<br>
&gt; arrange itself splitting itself to 3 categories(Assuming replica-2)<br>
&gt; 1) Files that are present in Node1, Node2<br>
&gt; 2) Files that are present in Node2, Node3<br>
&gt; 3) Files that are present in Node1, Node3<br>
&gt;<br>
&gt; As you can see we arrived at a contradiction where all the nodes should have<br>
&gt; at least 2 bricks but there is only 1 disk. Hence the contradiction. We<br>
&gt; can&#39;t do what you are asking without brick splitting. i.e. we need to split<br>
&gt; the disk into 2 bricks.<br>
<br>
</span>I don&#39;t think so.<br>
Let&#39;s assume a replica 2.<br>
<br>
S1B1 + S2B1<br>
<br>
1TB each, thus 1TB available (2TB/2)<br>
<br>
Adding a third 1TB disks should increase available space to 1.5TB (3TB/2)<br>
</blockquote></div><br>I agree it should. Question is how? What will be the resulting brick-map?<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>