[Bugs] [Bug 1471031] dht_(f)xattrop does not implement migration checks

[bugzilla at redhat.com]

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

Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rgowdapp at redhat.com



--- Comment #6 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Nithya Balachandran from comment #5)
> We may run into issues with dht_migrate_file and xattrops sent by the shard
> xlator where ,as the xattrop is an ADD operation, so this the wrong value
> could end up being set.
> 
> file  = data file
> file' = linkto file
> 
> Time                Source                                  Target
> -----------------------------------------------------------------------
> 
> t0                  file                                   file' 
>                     (shard.size = x1)
> 
> t1                  file  (listxattr)                      file'
>                     (shard.size = x1)
> 
> t2                  file                                   file' (setxattr) 
>                     shard.size=x1                          shard.size=x1
> 
> t3                  file (xattrop (ADD))                   file' 
>                     shard.size = x2                        (shard.size = x1)
>  [operation not performed on the target as this is not marked PHASE1 yet]
> 
> Now, a write + xattrop is performed after the S+T bits have been set.
> 
> t4                  file (S+T) (xattrop(ADD))             file'
>                     shard.size = x3                       (shard.size = x3')
> The operation is now performed on the target as well but the value will be
> different as it is an ADD performed in a different initial value.
> 
> 
> Convert target to data file
> t5                   file (S+T)                           file
>                      shard.size = x3                      (shard.size = x3')
> 
> A write + xattrop is now performed but is sent only to the target file (as
> it is now a data file on the hashed subvol)
> 
> t6                   file (S +T)                          file xattrop(ADD))
>                      shard.size = x3                      shard.size = x4
> 
> Copy xattrs again from src to target
> 
> t7                   file (S + T ) listxattr             file (setxattr
>                      shard.size = x3                     shard.size=x3
> 
> 
> Convert source to linkto
> 
> t8                   file'                               file 
>                      shard.size= x3                      (shard.size = x3)
> 
> 
> 
> The listxattr+setxattr at t7 would fix the race at t3. However, it
> introduces its own race and hence possible file corruption. 
> 
> 
> A possible solution would be to:
> 
> 1. Set the S+T bits before performing the initial listxattr + setxattr. This
> does not fix the race where xattrops may reach the dst out of order.

That's correct. This can still lead to a race where setxattr and xattrop can
reach dst out-of-order. This is very much similar to read from rebalance racing
with writes from a client discussed in [1][2]. Solution discussed in [2], when
extended to setxattr and xattrop can solve this race.

[1] https://github.com/gluster/glusterfs/issues/308
[2] https://github.com/gluster/glusterfs/issues/347

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vSL8vRR5e0&a=cc_unsubscribe