Description of problem: DHT: A directory with a null layout range on one or more subvols will cause lookup everywhere to be called for its contents. Version-Release number of selected component (if applicable): How reproducible: Consistently. Steps to Reproduce: I added the following log message to the dht_lookup_everywhere() function and did a source install: gf_msg_debug (this->name, 0, "winding lookup call to %d subvols", call_cnt); +gf_msg ("Nithya", GF_LOG_INFO, 0, 0, "Calling lookup everywhere on %s", loc->path); + 1. Create a 2 brick distribute volume, fuse mount it and create a directory dir1 2. Add a brick and rebalance the volume 3. Create a file inside dir1 and rename it so that a linkto file is created 4. Add a brick but do not run a rebalance. 5. Delete the linkto file from the backend brick. 6. Unmount and remount the volume 7. cd /mnt/gluster/dir1 Do not list the dir contents. 8. stat xyz1 Actual results: stat succeeds. The following message is printed in the mount logs: [2019-10-14 04:53:35.586127] I [MSGID: 0] [dht-common.c:2989:dht_lookup_everywhere] 0-Nithya: Calling lookup everywhere on /dir1/xyz1 The linkto file is recreated on the hashed brick. Expected results: stat should fail. Additional info: RCA: A null trusted.glusterfs.dht xattr has a null commit hash as well. When merging the disk layout information for the parent directory into the layout structure, dht_layout_merge() does the following: if (layout->commit_hash == 0) { layout->commit_hash = layout->list[i].commit_hash; } else if (layout->commit_hash != layout->list[i].commit_hash) { layout->commit_hash = DHT_LAYOUT_HASH_INVALID; } As the layout xattr on the newly added brick is 0, the layout->commit hash is set to DHT_LAYOUT_HASH_INVALID. In dht_lookup_cbk for xyz1, the parent_layout->commit_hash will not match the conf->vol_commit_hash, causing lookup everywhere to be called. The same behaviour is seen in 3.5.0.