[Gluster-devel] Barrier design issues wrt volume snapshot

[Vijay Bellur]

Adding gluster-devel.


On 03/06/2014 01:15 PM, Krishnan Parthasarathi wrote:
> All,
>
> In recent discussions around design (and implementation) of the barrier
> feature, couple of things came to light.
>
> 1) changelog xlator needs barrier xlator to block unlink and rename FOPs
>     in the call path. This is apart from the current list of FOPs that are blocked
>     in their call back path.
>     This is to make sure that the changelog has a bounded queue of unlink and rename FOPs,
>     from the time barriering is enabled, to be drained, committed to changelog file and published.
>
> 2) It is possible in a pure distribute volume that the following sequence of FOPs could result
>     in snapshots of bricks disagreeing on inode type for a file or directory.
>
>     t1: snap b1
>     t2: unlink /a
>     t3: mkdir /a
>     t4: snap b2
>
> where, b1 and b2 are bricks of a pure distribute volume V.
>
> The above sequence can happen with the current barrier xlator design, since we allow unlink FOPs
> to go through to the disk and only block their acknowledgement to the application. This implies
> a concurrent mkdir on the same name could succeed, since DHT doesn't serialize unlink and mkdir FOPs,
> unlike AFR.
>
> Avati,
>
> I hear that you have a solution for problem 2). Could you please start the discussion on this thread?
> It would help us to decide how to go about with the barrier xlator implementation.
>
> thanks,
> Krish
>