+++ This bug was initially created as a clone of Bug #1031016 +++ Description of problem: In case of DHT volume, brick logs has '(null)' as a path for operations like OPENDIR, MKDIR, MKNOD, SETXATTR e.g log snippet from brick [2013-11-14 01:52:01.592994] I [server-rpc-fops.c:705:server_opendir_cbk] 0-dht-server: 61510: OPENDIR (null) (16bb3787-361d-4977-8c66- a62b8d2f70a3) ==> (No such file or directory) [2013-11-14 03:14:56.011608] I [server-rpc-fops.c:528:server_mkdir_cbk] 0-dht-server: 32254: MKDIR (null) (00000000-0000-0000-0000-0000 00000001/{1.1000000}) ==> (File exists) [2013-11-14 03:18:18.304290] I [server-rpc-fops.c:438:server_access_cbk] 0-dht-server: 47194: ACCESS (null) (2d0887f8-358d-4758-949f-db bd06d67265) ==> (No such file or directory) [2013-11-14 03:18:18.317609] I [server-rpc-fops.c:705:server_opendir_cbk] 0-dht-server: 47197: OPENDIR (null) (2d0887f8-358d-4758-949f- dbbd06d67265) ==> (No such file or directory) ... [2013-11-14 06:32:14.172144] I [server-rpc-fops.c:898:_gf_server_log_setxattr_failure] 0-dht-server: 164153: SETXATTR (null) (85258d5e- fde6-4452-a4cf-71ef0568129a) ==> trusted.glusterfs.dht [2013-11-14 06:32:14.174551] I [server-rpc-fops.c:528:server_mkdir_cbk] 0-dht-server: 285540: MKDIR (null) (00000000-0000-0000-0000-000 000000001/118) ==> (File exists) [2013-11-14 06:32:14.202874] I [server-rpc-fops.c:575:server_mknod_cbk] 0-dht-server: 285551: MKNOD (null) (bf070eaf-2822-40b7-ab44-24d 91926db45/f7) ==> (File exists) In most of the cases reason is '(File exists)' or ' (No such file or directory)' Version-Release number of selected component (if applicable): ============================================================= 3.4.0.44rhs-1.el6rhs.x86_64 How reproducible: always Steps to Reproduce: 1.create DHT volume and mout it using FUSE and NFS 2. create, delete files/Directories from both mount point simultaneously. 3. Keep checking logs. Actual results: for many operation directory/file path is '(null)' in brick log Expected results: It should show path of that Dir/file Additional info: --- Additional comment from Amar Tumballi on 2013-12-02 05:09:24 EST --- (null) in here is the 'path' of the file. Yes it could have not been printed at all as a proper fix. Above there are two type of operations: inode ops (Access, opendir etc), where there is a log of 'gfid' which can help people to debug. (Also, these calls may be also path less, gfid only fops).. in entry ops: (mkdir and mknod), the gfid of parent, and basename is logged to help debugging.
REVIEW: http://review.gluster.org/11206 (dht: remove 'null' for directory/file path from brick log for many operations) posted (#1) for review on master by Sakshi Bansal (sabansal)
COMMIT: http://review.gluster.org/11206 committed in master by Raghavendra G (rgowdapp) ------ commit 546f66f546a9c9f63c4ee7d3f28fc3a494305263 Author: Sakshi <sabansal> Date: Fri Jun 12 19:42:30 2015 +0530 dht: remove 'null' for directory/file path from brick log for many operations Change-Id: I39cd2089240c0ad62b749f176847cc5337e57f73 BUG: 1231264 Signed-off-by: Sakshi <sabansal> Reviewed-on: http://review.gluster.org/11206 Tested-by: NetBSD Build System <jenkins.org> Reviewed-by: Shyamsundar Ranganathan <srangana> Reviewed-by: Raghavendra G <rgowdapp>
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-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user