Gluster users - May 2017 - Add single server

On Mon, May 1, 2017 at 11:20 PM, Gandalf Corvotempesta <
gandalf.corvotempesta at gmail.com> wrote:
> 2017-05-01 19:36 GMT+02:00 Pranith Kumar Karampuri <pkarampu at
redhat.com>:
> > To know GFID of file1 you must know where the file resides so that you
> can
> > do getxattr trusted.gfid on the file. So storing server/brick location
on
> > gfid is not getting us much more information that what we already
have.
>
> It was an example. You can use the same xattr solution based on a hash.
> A full-path for each volume is unique (obviously, you can't have two
> "/tmp/my/file" on the same volume), thus
> hashing that to something like SHA1("/tmp/my/file") will give you
a
> unique name (50b73d9c5dfda264d3878860ed7b1295e104e8ae)
> You can use that unique file-name (stored somewhere like
> ".metedata/50b73d9c5dfda264d3878860ed7b1295e104e8ae" to store the
> xattr with proper file locations across the cluster.
>
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.

>
> As long as you sync the ".metadata" directory across the trusted
pool
> (or across all member regarding the affected volume),
> you should be able to get proper file location by looking for the xattr.
>
> This is just a very basic and stupid POC, i'm just trying to explain
> my reasoning.
>
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 :-(.

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.

-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170501/61ce0a71/attachment.html>

2017-05-01 20:08 GMT+02:00 Pranith Kumar Karampuri <pkarampu at
redhat.com>:
> 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.
Filename can be renamed even with the current architecture.
How do you change the GFID after file rename ? In the same way you can
re-hash the file.
> 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 :-(.
mine was just a POC.

tl;dr: if you can save a mapping between files and brick, inside the
gluster cluster,
you'll get much more flexibility, no SPOF and no need for dedicated
metadata servers.
> 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.
What is brick-splitting ? Any docs about this ?