<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"><<a href="mailto:gandalf.corvotempesta@gmail.com" target="_blank">gandalf.corvotempesta@gmail.com</a>></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 <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>:<br>
> Yes this is precisely what all the other SDS with metadata servers kind of<br>
> do. They kind of keep a map of on what all servers a particular file/blob is<br>
> stored in a metadata server.<br>
<br>
</span>Not exactly. Other SDS has some servers dedicated to metadata and,<br>
personally, I don't like that approach.<br>
<span class=""><br>
> GlusterFS doesn't do that. In GlusterFS what<br>
> bricks need to be replicated is always given and distribute layer on top of<br>
> these replication layer will do the job of distributing and fetching the<br>
> data. Because replication happens at a brick level and not at a file level<br>
> and distribute happens on top of replication and not at file level. There<br>
> isn't too much metadata that needs to be stored per file. Hence no need for<br>
> separate metadata servers.<br>
<br>
</span>And this is great, that's why i'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>
> If you know path of the file, you can always know where the file is stored<br>
> using pathinfo:<br>
> Method-2 in the following link:<br>
> <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>
><br>
> You don't need any db.<br>
<br>
</span>For the current gluster yes.<br>
I'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't be able to read<br>
that.<br>
<br>
Something similiar could be added in gluster (i don'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 "metadata" stored in<br>
the fixed position.<br>
<br>
Like ".gluster" directory. Gluster is using some "internal"<br>
directories for internal operations (".shards", ".gluster", ".trash")<br>
A ".metadata" with file mapping would be hard to add ?<br>
<span class=""><br>
> Basically what you want, if I understood correctly is:<br>
> If we add a 3rd node with just one disk, the data should automatically<br>
> arrange itself splitting itself to 3 categories(Assuming replica-2)<br>
> 1) Files that are present in Node1, Node2<br>
> 2) Files that are present in Node2, Node3<br>
> 3) Files that are present in Node1, Node3<br>
><br>
> As you can see we arrived at a contradiction where all the nodes should have<br>
> at least 2 bricks but there is only 1 disk. Hence the contradiction. We<br>
> can't do what you are asking without brick splitting. i.e. we need to split<br>
> the disk into 2 bricks.<br>
<br>
</span>I don't think so.<br>
Let'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>