Bug Reporting Guidelines

Before filing a bug

If you are finding any issues, these preliminary checks as useful:

  • Is SELinux enabled? (you can use getenforce to check)
  • Are iptables rules blocking any data traffic? (iptables -L can help check)
  • Are all the nodes reachable from each other? [ Network problem ]
  • Please search Bugzilla to see if the bug has already been reported
    • Choose GlusterFS as the “product”, and then type something relevant in the “words” box. If you are seeing a crash or abort, searching for part of the abort message might be effective. If you are feeling adventurous you can select the “Advanced search” tab; this gives a lot more control but isn’t much better for finding existing bugs.
    • If a bug has been already filed for a particular release and you found the bug in another release,
      • please clone the existing bug for the release, you found the issue.
      • If the existing bug is against mainline and you found the issue for a release, then the cloned bug depends on should be set to the BZ for mainline bug.

Anyone can search in Bugzilla, you don’t need an account. Searching requires some effort, but helps avoid duplicates, and you may find that your problem has already been solved.

Reporting A Bug

  • You should have a Bugzilla account
  • Here is the link to file a bug: Bugzilla
  • The template for filing a bug can be found *here*

Note: Please go through all below sections to understand what information we need to put in a bug. So it will help the developer to root cause and fix it

Required Information

You should gather the information below before creating the bug report.

Package Information

  • Location from which the packages are used
  • Package Info - version of glusterfs package installed

Cluster Information

  • Number of nodes in the cluster
  • Hostnames and IPs of the gluster Node [if it is not a security issue]
    • Hostname / IP will help developers in understanding & correlating with the logs
  • Output of gluster peer status
  • Node IP, from which the “x” operation is done
    • “x” here means any operation that causes the issue

Volume Information

  • Number of volumes
  • Volume Names
  • Volume on which the particular issue is seen [ if applicable ]
  • Type of volumes
  • Volume options if available
  • Output of gluster volume info
  • Output of gluster volume status
  • Get the statedump of the volume with the problem

   $ gluster volume statedump 

This dumps statedump per brick process in /var/run/gluster

NOTE: Collect statedumps from one gluster Node in a directory.

Repeat it in all Nodes containing the bricks of the volume. All the so collected directories could be archived,compressed and attached to bug

Brick Information

  • xfs options when brick partition was done
    • This could be obtained with this command :

   $ xfs_info /dev/mapper/vg1-brick

  • Extended attributes on the bricks
    • This could be obtained with this command:

   $ getfattr -d -m. -ehex /rhs/brick1/b1

Client Information

  • OS Type ( Windows, RHEL )
  • OS Version : In case of Linux distro get the following :
   $ uname -r
   $ cat /etc/issue
  • Fuse or NFS Mount point on the client with output of mount commands
  • Output of df -Th command

Tool Information

  • If any tools are used for testing, provide the info/version about it
  • if any IO is simulated using a script, provide the script

Logs Information

  • You can check logs for check for issues/warnings/errors.
    • Self-heal logs
    • Rebalance logs
    • Glusterd logs
    • Brick logs
    • NFS logs (if applicable)
    • Samba logs (if applicable)
    • Client mount log
  • Add the entire logs as attachment, if its very large to paste as a comment

SOS report for CentOS/Fedora

  • Get the sosreport from the involved gluster Node and Client [ in case of CentOS /Fedora ]
  • Add a meaningful name/IP to the sosreport, by renaming/adding hostname/ip to the sosreport name