Description of problem:

There is no test case. This issue was found during design review of barrier xlator. A pure distribute volume having more than one subvolume is the setup.

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.

The solution is to serialize operations on same entry in server.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: