[Bugs] [Bug 1163161] New: With afrv2 + ext4, lookups on directories with large offsets could result in duplicate/missing entries

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1163161

            Bug ID: 1163161
           Summary: With afrv2 + ext4, lookups on directories with large
                    offsets could result in duplicate/missing entries
           Product: GlusterFS
           Version: mainline
         Component: core
          Assignee: bugs at gluster.org
          Reporter: skoduri at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Description of problem:

'ext4' uses large offsets which may include the bits used by GlusterFS to
encode the brick-id. This could end up in few offsets being modified when given
back to the filesystem resulting in missing files and other such discrepancies.

Avati has proposed a solution to overcome this issue based on the assumption
that "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. For more info, please check
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.