<div>Hello,</div><div><br></div><div>Recently I spent a bit time understanding rebalance since I want to know its</div><div>performance given that there could be more and more bricks to be added into</div><div>my glusterfs volume and there will be more and more files and directories</div><div>in the existing glusterfs volume. During the test I saw something which I'm</div><div>really confused about.</div><div><br></div><div>Steps:</div><div><br></div><div><span style="line-height: 1.5;">SW versions: glusterfs 3.4.4 + centos 6.5</span></div><div>Inital Configuration: replica 2, lab1:/brick1 + lab2:/brick1</div><div><br></div><div>fuse_mount it on /mnt</div><div>cp -rf /sbin /mnt (~300+ files under /sbin)</div><div>add two more bricks: lab1:/brick2 + lab2:/brick2.</div><div>run gluster reblance.</div><div><br></div><div>1) fix-layout only&nbsp;<span style="line-height: 1.5;">(e.g. gluster volume rebalance g1 fix-layout start)<span id="_editor_bookmark_start_3" style="display: none; line-height: 0px;">‍</span></span></div><div><span style="line-height: 1.5;"><br></span></div><div><span style="line-height: 1.5;">After rebalance is done (observed via "</span>gluster volume rebalance g1 status"),<span id="_editor_bookmark_start_4" style="display: none; line-height: 0px;">‍</span></div><div>I found there is no file under lab1:/brick2/sbin. T<span style="line-height: 1.5;">he hash ranges of</span></div><div><span style="line-height: 1.5;">new brick</span><span style="line-height: 1.5;">&nbsp;<span id="_editor_bookmark_start_9" style="display: none; line-height: 0px;">‍</span></span><span style="line-height: 1.5;">lab1:/brick2/sbin and old brick lab1:/brick1/sbin appear to</span></div><div>be ok.</div><div><br></div><div><div>[root@lab1 Desktop]# getfattr -dm. -e hex /brick2/sbin</div><div>getfattr: Removing leading '/' from absolute path names</div><div># file: brick2/sbin</div><div>trusted.gfid=0x35976c2034d24dc2b0639fde18de007d</div><div>trusted.glusterfs.dht=0x00000001000000007fffffffffffffff</div><div><br></div><div><span style="line-height: 1.5;">[root@lab1 Desktop]# getfattr -dm. -e hex /brick1/sbin</span></div><div>getfattr: Removing leading '/' from absolute path names</div><div># file: brick1/sbin</div><div>trusted.gfid=0x35976c2034d24dc2b0639fde18de007d</div><div>trusted.glusterfs.dht=0x0000000100000000000000007ffffffe</div></div><div><span id="_editor_bookmark_start_5" style="display: none; line-height: 0px;">‍</span><br></div><div>The question is: AFAIK, fix-layout would create "linkto" files</div><div>(files with "linkto" xattr and with sticky bit set only)</div><div>for those ones whose hash values belong</div><div>to the new subvol. so there should have been some "linkto" files</div><div>under lab1:/brick2, but no one now, why?</div><div><br></div><div><span style="line-height: 1.5;">2)&nbsp;</span><span style="line-height: 1.5;">fix-layout + data_migrate (e.g. gluster volume rebalance g1 start)</span></div><div><br></div><div>After migration is done, I saw linkto files under brick2/sbin.<span id="_editor_bookmark_start_0" style="display: none; line-height: 0px;">‍</span></div><div>There are totally 300+ files under system /sbin. Under brick2/sbin,</div><div>I found the 300+ files are all there!&nbsp;<span style="line-height: 1.5;">either migrated or linkto-ed.</span></div><div><br></div><div><div><span style="line-height: 1.5;">-rwxr-xr-x 2 root root &nbsp; 17400 Sep 10 12:02 vmcore-dmesg</span></div><div>---------T 2 root root &nbsp; &nbsp; &nbsp; 0 Sep 10 12:03 weak-modules</div><div>---------T 2 root root &nbsp; &nbsp; &nbsp; 0 Sep 10 12:03 wipefs</div><div>-rwxr-xr-x 2 root root &nbsp;295656 Sep 10 12:02 xfsdump</div><div>-rwxr-xr-x 2 root root &nbsp;510000 Sep 10 12:02 xfs_repair</div><div>-rwxr-xr-x 2 root root &nbsp;348088 Sep 10 12:02 xfsrestore</div></div><div><br></div><div>And under brick1/sbin, those migrated files are gone as expected.</div><div>There are near to 150 files under brick/sbin.</div><div><span id="_editor_bookmark_start_1" style="display: none; line-height: 0px;">‍</span><br></div><div>This confuses me since creating those linkto files seems to</div><div>be unnecessary, at least for files whose hash values do not belong</div><div>to the subvol. (My understanding is that if a file's hash value is</div><div>in the range of a subvol then it will be stored in that subvol.)</div><div><br></div><div>I quickly looked at the code. <span style="line-height: 1.5;">gf_defrag_start_crawl() appears to</span></div><div><span style="line-height: 1.5;">be the function for this operation. I do see code that does file migration</span></div><div><span style="line-height: 1.5;">from the code path, but debugging code shows that those "linkto" files</span></div><div><span style="line-height: 1.5;">seem to be not created by gf_defrag_start_crawl(). I'm not that familar with</span></div><div><span style="line-height: 1.5;">the code detail and the theory so I'm not sure who created those</span></div><div><span style="line-height: 1.5;">"linkto" files and why the "linkto" file are created.</span></div><div><span style="line-height: 1.5;"><br></span></div><div><span style="line-height: 1.5;">Thanks,</span></div><div><span style="line-height: 1.5;">Paul</span></div>