On Mon, May 1, 2017 at 10:57 PM, Gandalf Corvotempesta <gandalf.corvotempesta@xxxxxxxxx> wrote:
2017-05-01 19:12 GMT+02:00 Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx>:
> 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="306040e474f199e7969ec266afd10d 93" <<---- 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 Gluster-users@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-users
