[Bugs] [Bug 1641429] Gfid mismatch seen on shards when lookup and mknod are in progress at the same time
bugzilla at redhat.com
bugzilla at redhat.com
Thu Oct 25 13:12:11 UTC 2018
Worker Ant <bugzilla-bot at gluster.org> changed:
What |Removed |Added
--- Comment #2 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/21453 committed in release-5 by "Krutika
Dhananjay" <kdhananj at redhat.com> with a commit message- storage/posix: Do not
fail entry creation fops if gfid handle already exists
> Change-Id: I84a5e54d214b6c47ed85671a880bb1c767a29f4d
> Signed-off-by: Krutika Dhananjay <kdhananj at redhat.com>
> (cherry picked from commit 15c9976)
> BUG: 1638453
tests/bugs/shard/bug-1251824.t fails occasionally with EIO due to gfid
mismatch across replicas on the same shard when dd is executed.
Turns out this is due to a race between posix_mknod() and posix_lookup().
posix mknod does 3 operations, among other things:
1. creation of the entry itself under its parent directory
2. setting the gfid xattr on the file, and
3. creating the gfid link under .glusterfs.
Consider a case where the thread doing posix_mknod() (initiated by shard)
has executed steps 1 and 2 and is on its way to executing 3. And a
parallel LOOKUP from another thread on noting that loc->inode->gfid is NULL,
tries to perform gfid_heal where it attempts to create the gfid link
under .glusterfs and succeeds. As a result, posix_gfid_set() through
MKNOD (step 3) fails with EEXIST.
In the older code, MKNOD under such conditions was NOT being treated
as a failure. But commit e37ee6d changes this behavior by failing MKNOD,
causing the entry creation to be undone in posix_mknod() (it's another
matter that the stale gfid handle gets left behind if lookup has gone
ahead and gfid-healed it).
All of this happens on only one replica while on the other MKNOD succeeds.
Now if a parallel write causes shard translator to send another MKNOD
of the same shard (shortly after AFR releases entrylk from the first
MKNOD), the file is created on the other replica too, although with a
new gfid (since "gfid-req" that is passed now is a new UUID. This leads
to a gfid-mismatch across the replicas.
The solution is to not fail MKNOD (or any other entry fop for that matter
that does posix_gfid_set()) if the .glusterfs link creation fails with EEXIST.
Signed-off-by: Krutika Dhananjay <kdhananj at redhat.com>
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs