[Gluster-devel] Rebalance data migration and corruption

Raghavendra Gowdappa rgowdapp at redhat.com
Fri Feb 5 11:02:40 UTC 2016


+gluster-devel

> 
> Hi Sakshi/Susant,
> 
> - There is a data corruption issue in migration code. Rebalance process,
>   1. Reads data from src
>   2. Writes (say w1) it to dst
> 
>   However, 1 and 2 are not atomic, so another write (say w2) to same region
>   can happen between 1. But these two writes can reach dst in the order (w2,
>   w1) resulting in a subtle corruption. This issue is not fixed yet and can
>   cause subtle data corruptions. The fix is simple and involves rebalance
>   process acquiring a mandatory lock to make 1 and 2 atomic.

We can make use of compound fop framework to make sure we don't suffer a significant performance hit. Following will be the sequence of operations done by rebalance process:

1. issues a compound (mandatory lock, read) operation on src.
2. writes this data to dst.
3. issues unlock of lock acquired in 1.

Please co-ordinate with Anuradha for implementation of this compound fop.

Following are the issues I see with this approach:
1. features/locks provides mandatory lock functionality only for posix-locks (flock and fcntl based locks). So, mandatory locks will be posix-locks which will conflict with locks held by application. So, if an application has held an fcntl/flock, migration cannot proceed.
2. data migration will be less efficient because of an extra unlock (with compound lock + read) or extra lock and unlock (for non-compound fop based implementation) for every read it does from src.

Comments?

> 
> regards,
> Raghavendra.


More information about the Gluster-devel mailing list