Bug 1761311

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.