Description of problem: The logs seem to be logging debug-level events in the info level for every file upload when using the cluster.extra-hash-regex option. Version-Release number of selected component (if applicable): Gluster 3.7.5 How reproducible: Consistent Steps to Reproduce: 1. Setup option cluster.extra-hash-regex: "(.*)\\.tmp" 2. Mount gluster client 3. Upload a file 4. Observe the logs Actual results: [2016-03-15 07:20:57.082917] I [MSGID: 109066] [dht-rename.c:1411:dht_rename] 0-gv0-dht: renaming /files/nas/1d/af/1dafc0f7f7d43000e4307550a2d60e13.tmpphpCM33fN_1944338764 (hash=gv0-replicate-0/cache=gv0-replicate-0) => /files/nas/1d/a/1dafc0f7f7d43000e4307550a2d60e13 (hash=gv0-replicate-0/cache=<nul>) Expected results: No logging event for a rename. Additional info: I believe this was a debug in 3.4 as I didn't see these messages.
This was from http://review.gluster.org/8582
This should be gf_msg_trace IMHO.
This was added to help with debugging - renames (both files and dirs) sometimes caused some rather odd issues and there was no other way to figure out if a rename operation had occurred. This little log message has helped us figure out what had happened while debugging several issues. To be clear, the issues this helped us debug refer to those caused by interactions between renames and layout changes. It does not refer to rename failures per se. It is also unrelated to the cluster.extra-hash-regex setting I would like to keep this around a tad longer.
In production this adds a huge amount of logging. If you need this debug info, can't you just set it to debug and enable debug logging? Why is this in production logs?
Setting it to debug does not help because we usually have to figure out what happend after the problem would have already occurred. Most users usually do not keep track of what ops were performed on a file and this message has helped us out in quite a few cases.
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life. Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS. If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.