Hi,
With Change-Id:Ieba9a7071829d51860b7c131982f12e0136b9855 , dht
itansform/deitransform was improved to encode 64-bit brick offset along
with the brick-id in the global d_off.
More details regarding this change are in :
http://review.gluster.org/#/c/4711/
But now with afr using the same itransform/deitransform logic, the
brick-id stored in the afr_global_d_off gets zeroed out when re-encoded
in dht. This happens only when the offsets are huge (i.e with ext4
filesystem) as in such cases, the low n bits are replaced with brick-id
which in turn gets replaced with afr_subvol_id when re-encoded in dht, where
n = log2(N)
N = no. of DHT/AFR subvolumes.
To avoid this, instead of using the last 'n' bits, we have decided to
store the brick/subvol-id in the first 'n' bits leaving the TOP_BIT i.e,
the brick/subvol offset will be first shifted by 'n' bits to the right
and then the brick-id is copied into those first 'n' bits.
This approach as well may result in the loss of few lower bits of the
brick_offset. But as mentioned in the review#4711, since "both EXT4/XFS
are tolerant in terms of the accuracy of the value presented back in
seekdir(). i.e, a seekdir(val) actually seeks to the entry which has the
"closest" true offset.", this approach too seems to work.
Also this brick_id encoding change is necessary even in case of small
offsets, as the smaller offset in the AFR translator could result in a
large offset when passed to DHT which may again result in the loss of
brick_id.
Changes and the modified algorithm have been posted to the review URL -
review.gluster.org/#/c/8201
Kindly review the changes and give us your feedback.
Thanks,
Soumya
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
