Description of problem:
The brick op of inode status commands fails on a distributed volumes as it fails to acquire lock.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a distributed replicated volume.
2. mount it and create a lot of files.
3. issue gluster volume status volname inodes
Commit fails on the remote nodes.
should print the inodes status output with the connections. without the commit failing (prints it as commit failed but its a brickop failure.)
REVIEW: https://review.gluster.org/20035 (Core: The lock contention on gf_client_dump_inodes_to_dict) posted (#1) for review on master by hari gowtham
COMMIT: https://review.gluster.org/20035 committed in master by "Amar Tumballi" <email@example.com> with a commit message- Core: The lock contention on gf_client_dump_inodes_to_dict
Problem: For a distributed replicated volume, in the inode status
command the lock on gf_client_dump_inodes_to_dict is held by the
first brickop. while this is being processed, if the second brickop
comes. It fails to get the lock and the whole brick op fails.
Fix: Instead of using a TRY_LOCK which errors out if the lock is busy,
Use LOCK which will wait till the lock is acquired.
Signed-off-by: hari gowtham <firstname.lastname@example.org>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-5.0, please open a new bug report.
glusterfs-5.0 has been announced on the Gluster mailinglists , packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist  and the update infrastructure for your distribution.