On Mon, May 1, 2017 at 10:57 PM, Gandalf Corvotempesta < [email protected]> wrote:
> 2017-05-01 19:12 GMT+02:00 Pranith Kumar Karampuri <[email protected]>: > > 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
_______________________________________________ Gluster-users mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
