Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: On DHT volume if User creates Directory when one or more sub-volume is down then self heal should create Directory on down sub volume when it comes online. But it should not fix hash layout for the same Directory. Only rebalance should fix layout. Right now when Sub-volumes come back Directories are healed on down sub-volume and hash layout is being fixed for few directories(not on all and how it choose those Directory is not consistent) Version-Release number of selected component (if applicable): 3.4.0.53rhs-1.el6rhs.x86_64 How reproducible: always Steps to Reproduce: 1. create DHT volume and mount using FUSE 2. bring down one or more subvolumes by killing brick process 3. create Directories from mount point 4. bring subvolume up by start force option. 5. from mount point execute commands which lookup for those directories 6. verify hash layout for those directories in backend Actual results: Directory layout on sub-volume which was down # file: rhs/brick1/b3/new20 trusted.gfid=0x3bcc2d8e106c4b37804ea4dee34566e6 trusted.glusterfs.dht=0x000000010000000099999999cccccccb <----------- # file: rhs/brick1/b3/new21 trusted.gfid=0x2bfeeeccc18b4e5bac002bc7e04c23d4 trusted.glusterfs.dht=0x00000001000000000000000000000000 # file: rhs/brick1/b3/new22 trusted.gfid=0xc10feccfcae448dd856d44436b9fd8bc trusted.glusterfs.dht=0x00000001000000000000000000000000 # file: rhs/brick1/b3/new23 trusted.gfid=0x0afb356f1ea448deb32a211fd6049aad trusted.glusterfs.dht=0x000000010000000099999999cccccccb <----------- # file: rhs/brick1/b3/new25 trusted.gfid=0x8be3eac8fc4b4c2da6b1c2158a7d37cf trusted.glusterfs.dht=0x00000001000000000000000000000000 It is fixing hash layout for few Directories Expected results: Self heal should not fix hash layout of Directories Additional info:
Created attachment 846997 [details] log
Created attachment 846998 [details] log
Testing for regression versus existing behaviour as in comment #6 and comment #7 in bug #1049771 was attempted and found the same behavior in BegBend and Corbett. Looks like the root cause is the same for both bugs, but as scenarios are different we can continue to track them separately.
Per 1/16 triage.
Per triage 1/16, Removing from the Corbett list
Cloning this to 3.1. To be fixed in future.