<div dir="ltr"><div><div><div><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 10:00 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">2017-05-01 18:23 GMT+02:00 Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>:<br>
> IMHO It is difficult to implement what you are asking for without metadata<br>
> server which stores where each replica is stored.<br>
<br>
</span>Can't you distribute a sort of file mapping to each node ?<br>
AFAIK , gluster already has some metadata stored in the cluster, what<br>
is missing is a mapping between each file/shard and brick.<br></blockquote><div><br>Yes this is precisely what all the other SDS with metadata servers kind of do. They kind of keep a map of on what all servers a particular file/blob is stored in a metadata server. GlusterFS doesn't do that. In GlusterFS what bricks need to be replicated is always given and distribute layer on top of these replication layer will do the job of distributing and fetching the data. Because replication happens at a brick level and not at a file level and distribute happens on top of replication and not at file level. There isn't too much metadata that needs to be stored per file. Hence no need for separate metadata servers.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Maybe a simple DB (just as an idea: sqlite, berkeleydb, ...) stored in<br>
a fixed location on gluster itself, being replicated across nodes.<br>
</blockquote></div>If you know path of the file, you can always know where the file is stored using pathinfo:<br>Method-2 in the following link: <a href="https://gluster.readthedocs.io/en/latest/Troubleshooting/gfid-to-path/">https://gluster.readthedocs.io/en/latest/Troubleshooting/gfid-to-path/</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">You don't need any db.<br></div><br></div>Basically what you want, if I understood correctly is:<br></div>If we add a 3rd node with just one disk, the data should automatically arrange itself splitting itself to 3 categories(Assuming replica-2)<br></div>1) Files that are present in Node1, Node2<br></div>2) Files that are present in Node2, Node3<br></div>3) Files that are present in Node1, Node3<br><div><div><div><div><div><br></div><div>As you can see we arrived at a contradiction where all the nodes should have at least 2 bricks but there is only 1 disk. Hence the contradiction. We can't do what you are asking without brick splitting. i.e. we need to split the disk into 2 bricks.<br></div><div><br><div class="gmail_extra">-- <br><div class="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div></div></div></div></div></div>