[Bugs] [Bug 1747844] Rebalance doesn't work correctly if performance.parallel-readdir on and with some other specific options set

bugzilla at redhat.com bugzilla at redhat.com
Wed Oct 16 12:19:22 UTC 2019


https://bugzilla.redhat.com/show_bug.cgi?id=1747844

Nithya Balachandran <nbalacha at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
              Flags|                            |needinfo?(Howard.Chen at infor
                   |                            |trend.com)



--- Comment #2 from Nithya Balachandran <nbalacha at redhat.com> ---
Hi,

Apologies for the delay but I finally managed to spend some time on this. Here
is what I have so far:

Release 4 is EOL so I tried with release-5.

I used Fuse not NFS and could not reproduce the issue with rebalance - the
contents of all directories were being migrated to the new bricks.
I did however see an issue where I could not list the directories from the fuse
mount immediately after they were created. This issue was not seen with
parallel-readdir off.

[root at rhgs313-7 ~]# glusterd; gluster v create test 
192.168.122.7:/bricks/brick1/t-{1..5} ; gluster v set test readdir-ahead on;
gluster v set test parallel-readdir on; gluster v start test;
volume create: test: success: please start the volume to access data
volume set: success
volume set: success
volume start: test: success
[root at rhgs313-7 ~]# mount -t glusterfs -s 192.168.122.7:/test /mnt/fuse1
[root at rhgs313-7 ~]# cd /mnt/fuse1/; mkdir dir_1; mkdir dir_1/dir_2; mkdir
dir_1/dir_2/dir_3; mkdir dir_1/dir_2/dir_3/dir_4
[root at rhgs313-7 fuse1]# ll
total 0



On further analysis, this was happening because the stat information for the
dirs received in dht_readdirp_cbk was invalid because of which dht will strip
those entries out of the listing. This was fixed by
https://review.gluster.org/#/c/glusterfs/+/21811/ and is available from
release-6 onwards.

It is possible that the same issue occurred on your volume so rebalance never
processed these dirs. As the log-level as been set to ERROR, there are no
messages in the rebalance log which can be used to figure out what happened.

Please do the following:
1. Enable info level logging for client-log-level, reproduce the issue and send
me the rebalance log.
2. Upgrade to release 6.x and see if you can still see the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Bugs mailing list