[Gluster-users] Add single server

Pranith Kumar Karampuri pkarampu at redhat.com
Mon May 1 17:36:22 UTC 2017


On Mon, May 1, 2017 at 10:57 PM, Gandalf Corvotempesta <
gandalf.corvotempesta at gmail.com> wrote:

> 2017-05-01 19:12 GMT+02:00 Pranith Kumar Karampuri <pkarampu at redhat.com>:
> > I agree it should. Question is how? What will be the resulting brick-map?
>
> This is why i'm suggesting to add a file mapping somewhere.
> You could also use xattr for this:
>
> "file1" is mapped to GFID, then, as xattr for that GFID, you could
> save the server/brick location, it this
> way you always know where a file is.
>

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.


>
> To keep it simple for non-developers like me (this is wrong, it's a
> simplification):
> "/tmp/file1" hashes to 306040e474f199e7969ec266afd10d93
>
> hash starts with "3" thus is located on brick3
>
> You don't need any metadata for this, the hash algoritm is the only
> thing you need.
>
> But if you store the file location mapping somewhere (in example as
> xattr for the GFID file) you can look for the file without using the
> hash algoritm location.
>
> ORIG_FILE="/tmp/file1"
>


> GFID="306040e474f199e7969ec266afd10d93" <<---- How did we get GFID?
>

May be I didn't understand your solution properly.


> FILE_LOCATION=$(getfattr -n "file_location" $GFID)
>
> if $FILE_LOCATION
>    read from $FILE_LOCATION
> else
>    read from original algoritm
>



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


More information about the Gluster-users mailing list