<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 11:20 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 19:36 GMT+02:00 Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>>:<br>
> To know GFID of file1 you must know where the file resides so that you can<br>
> do getxattr trusted.gfid on the file. So storing server/brick location on<br>
> gfid is not getting us much more information that what we already have.<br>
<br>
</span>It was an example. You can use the same xattr solution based on a hash.<br>
A full-path for each volume is unique (obviously, you can't have two<br>
"/tmp/my/file" on the same volume), thus<br>
hashing that to something like SHA1("/tmp/my/file") will give you a<br>
unique name (<wbr>50b73d9c5dfda264d3878860ed7b12<wbr>95e104e8ae)<br>
You can use that unique file-name (stored somewhere like<br>
".metedata/<wbr>50b73d9c5dfda264d3878860ed7b12<wbr>95e104e8ae" to store the<br>
xattr with proper file locations across the cluster.<br></blockquote><div><br></div><div>Filename can be renamed and then we lost the link because hash will be different. Anyways all these kinds of problems are already solved in distribute layer.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As long as you sync the ".metadata" directory across the trusted pool<br>
(or across all member regarding the affected volume),<br>
you should be able to get proper file location by looking for the xattr.<br>
<br>
This is just a very basic and stupid POC, i'm just trying to explain<br>
my reasoning.<br>
</blockquote></div>I am sorry at the moment with the given information I am not able to wrap my head around the solution you are trying to suggest :-(.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">At the moment, brick-splitting, inversion of afr/dht has some merit in my mind, with tilt towards any solution that avoids this inversion and still get the desired benefits.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div></div>