Description of problem: After we add-brick and fix-layout,the function fuse_thread_proc is still blocked in readv,The old graph will be executed first.The first time we create a file on the client, we will get an incorrect hash volume. Version-Release number of selected component (if applicable): all Steps to Reproduce: 1.[node1]# gluster volume info Volume Name: dht_vol Type: Distribute Volume ID: f99cc88b-9558-4286-a56e-3bcb7d057035 Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: 10.10.21.150:/root/sdb Options Reconfigured: performance.readdir-ahead: on 2.[node3]# mount.glusterfs node1:/dht_vol /mnt/gluster/ 3.[node1]# gluster volume add-brick dht_vol 10.10.21.150:/root/sdc force [node1]# gluster volume rebalance dht_vol fix-layout start 4.[node3]# touch 0 5.[node1]# ls sd* sdb: sdc: 0 6.[node3]# rm 0 -rf; touch 0 7.[root@node1 ~]# ls sd* sdb: 0 sdc: Actual results: step 3-4: the first time we create a file, 0 is distributed in sdc. step 5-6: but the second time,file 0 is distributed in sdb Expected results: step 5-6: We hope file 0 should belong to the same brick Additional info: I have a solution for this problem.we can move the function fuse_graph_sync back to readv .I've tested it, it's right.But I don't know if it will bring other problems. Waiting for your answer. Thank you.
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#2) for review on master by wangzhen (linux_wz)
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#3) for review on master by wangzhen (linux_wz)
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#4) for review on master by wangzhen (linux_wz)
REVIEW: http://review.gluster.org/11734 (fuse: Get an incorrect hash volume after we add-brick) posted (#1) for review on master by wangzhen (linux_wz)
In the above tests (comment 1), we are not waiting till fix-layout is complete before creating file in step 4. Can you please re-run the tests with creating the file once fix-layout is complete? You can monitor the status of rebalance using: #gluster volume rebalance dht_vol status My suspicion is that file got created in step 4 before rebalance was able to fix the layout.
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#5) for review on master by wangzhen (linux_wz)
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#6) for review on master by wangzhen (linux_wz)
changing version to mainline in order to retire pre-release. If you know the appropriate, correct version for this bug, please set it.
REVIEW: http://review.gluster.org/11672 (fuse: Get an incorrect hash volume after we add-brick) posted (#7) for review on master by Niels de Vos (ndevos)
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
The DHT code determines the brick on which to create the file based on the where the hash of the file name falls according to the layout of the parent directory. This may change based on whether the bricks topology has been updated and whether a rebalance/fix-layout has been run. That being said, it seems odd that the layout has changed from the new brick to the old. This may have been because of the way the older dht layout code worked. Recent changes where the layout will not be changed if it is already complete and spans the bricks will probably prevent this behaviour from showing up.
Fixed by https://review.gluster.org/14763