gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] Barrier design issues wrt volume snapshot


From: Vijay Bellur
Subject: Re: [Gluster-devel] Barrier design issues wrt volume snapshot
Date: Thu, 06 Mar 2014 13:51:16 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]