<div>Hello Shyam. Thanks for the reply. Please see my reply below, starting with [paul:]</div><div><br></div><div>Please add me in address list besides gluster-uses when replying so that I can easier</div><div>reply since I subscribed gluster-users with the digest mode (No other choice if I</div><div>remember&nbsp;<span style="line-height: 1.5;">correctly.)</span></div><div><br></div><div>Date: Wed, 10 Sep 2014 10:36:41 -0400<br>From: Shyam &lt;srangana@redhat.com&gt;<br>To: gluster-users@gluster.org<br>Subject: Re: [Gluster-users] Questions about gluster reblance<br>Message-ID: &lt;541061F9.7000800@redhat.com&gt;<br>Content-Type: text/plain; charset=UTF-8; format=flowed<br><br>On 09/10/2014 03:27 AM, Paul Guo wrote:<br>&gt; Hello,<br>&gt;<br>&gt; Recently I spent a bit time understanding rebalance since I want to know its<br>&gt; performance given that there could be more and more bricks to be added into<br>&gt; my glusterfs volume and there will be more and more files and directories<br>&gt; in the existing glusterfs volume. During the test I saw something which I'm<br>&gt; really confused about.<br>&gt;<br>&gt; Steps:<br>&gt;<br>&gt; SW versions: glusterfs 3.4.4 + centos 6.5<br>&gt; Inital Configuration: replica 2, lab1:/brick1 + lab2:/brick1<br>&gt;<br>&gt; fuse_mount it on /mnt<br>&gt; cp -rf /sbin /mnt (~300+ files under /sbin)<br>&gt; add two more bricks: lab1:/brick2 + lab2:/brick2.<br>&gt; run gluster reblance.<br>&gt;<br>&gt; 1) fix-layout only (e.g. gluster volume rebalance g1 fix-layout start)?<br>&gt;<br>&gt; After rebalance is done (observed via "gluster volume rebalance g1<br>&gt; status"),?<br>&gt; I found there is no file under lab1:/brick2/sbin. The hash ranges of<br>&gt; new brick?lab1:/brick2/sbin and old brick lab1:/brick1/sbin appear to<br>&gt; be ok.<br>&gt;<br>&gt; [root@lab1 Desktop]# getfattr -dm. -e hex /brick2/sbin<br>&gt; getfattr: Removing leading '/' from absolute path names<br>&gt; # file: brick2/sbin<br>&gt; trusted.gfid=0x35976c2034d24dc2b0639fde18de007d<br>&gt; trusted.glusterfs.dht=0x00000001000000007fffffffffffffff<br>&gt;<br>&gt; [root@lab1 Desktop]# getfattr -dm. -e hex /brick1/sbin<br>&gt; getfattr: Removing leading '/' from absolute path names<br>&gt; # file: brick1/sbin<br>&gt; trusted.gfid=0x35976c2034d24dc2b0639fde18de007d<br>&gt; trusted.glusterfs.dht=0x0000000100000000000000007ffffffe<br>&gt; ?<br>&gt; The question is: AFAIK, fix-layout would create "linkto" files<br>&gt; (files with "linkto" xattr and with sticky bit set only)<br>&gt; for those ones whose hash values belong<br>&gt; to the new subvol. so there should have been some "linkto" files<br>&gt; under lab1:/brick2, but no one now, why?<br><br>fix-layout only fixes the layout, i.e spreads the layout to the newer <br>bricks (or bricks previously not participating in the layout). It would <br>not create the linkto files.<br><br>Post fix-layout, if one were to perform a lookup on a file, that should <br>have belonged to the newer brick as per the layout and hash of that file <br>name, one can see the linkto file being present.</div><div><br>Hope this explains (1).<br></div><div><br></div><div>[paul:]</div><div><br></div><div>After fix-layout is complete, I mount the volume on /mnt, then&nbsp;</div><div>run "ls -l /mnt/sbin/*" and "file /mnt/sbin/*",</div><div>and then I found just several linkto files are created while most files,</div><div>which should have&nbsp;<span style="line-height: 1.5;">been created under the new brick (i.e. brick2),</span></div><div><span style="line-height: 1.5;">are not created.</span></div><div><span style="line-height: 1.5;">[root@lab1 ~]# ls -l /brick2/sbin</span></div><div><div>total 0</div><div>---------T 2 root root 0 Sep 12 09:26 dmraid</div><div>---------T 2 root root 0 Sep 12 09:26 initctl</div><div>---------T 2 root root 0 Sep 12 09:26 ip6tables-multi</div><div>---------T 2 root root 0 Sep 12 09:26 portreserve</div><div>---------T 2 root root 0 Sep 12 09:26 reboot</div><div>---------T 2 root root 0 Sep 12 09:26 swapon</div><div><div>[root@lab1 ~]# getfattr -dm. -e hex /brick2/sbin</div><div>getfattr: Removing leading '/' from absolute path names</div><div># file: brick2/sbin</div><div>trusted.gfid=0x94bc07cd18914a91ab12fbe931c63431</div><div>trusted.glusterfs.dht=0x00000001000000007fffffffffffffff</div></div><div><span style="line-height: 1.5;">[root@lab1 ~]# ./gethash.py reboot</span></div><div><div>0xd48b11f6L</div><div>[root@lab1 ~]# ./gethash.py swapon</div><div>0x93129578L</div><div><br></div><div>The hash values of reboot &amp; swapon are in the range of</div><div>/brick2/sbin (i.e. 7fffFFFF - ffffFFFF) so the linkto files</div><div>for the two binaries are expected, but there are more</div><div>linkto files missing, e.g. xfsdump</div><div><span style="line-height: 1.5;">[root@lab1 ~]# ./gethash.py xfsdump</span></div><div>0xc17ff86bL</div><div><br></div></div><div>Even I umount /mnt, stop-then-start the volume,</div><div>restart glusterd, remount /mnt and then do the experiment</div><div>again, I still find no more linkto files under /brick2/sbin.</div><div><br></div><div><span style="line-height: 1.5;">&gt;</span></div>&gt; 2) fix-layout + data_migrate (e.g. gluster volume rebalance g1 start)<br>&gt;<br>&gt; After migration is done, I saw linkto files under brick2/sbin.?<br>&gt; There are totally 300+ files under system /sbin. Under brick2/sbin,<br>&gt; I found the 300+ files are all there! either migrated or linkto-ed.<br>&gt;<br>&gt; -rwxr-xr-x 2 root root&nbsp;&nbsp; 17400 Sep 10 12:02 vmcore-dmesg<br>&gt; ---------T 2 root root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 Sep 10 12:03 weak-modules<br>&gt; ---------T 2 root root&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 Sep 10 12:03 wipefs<br>&gt; -rwxr-xr-x 2 root root&nbsp; 295656 Sep 10 12:02 xfsdump<br>&gt; -rwxr-xr-x 2 root root&nbsp; 510000 Sep 10 12:02 xfs_repair<br>&gt; -rwxr-xr-x 2 root root&nbsp; 348088 Sep 10 12:02 xfsrestore<br>&gt;<br>&gt; And under brick1/sbin, those migrated files are gone as expected.<br>&gt; There are near to 150 files under brick/sbin.<br>&gt; ?<br>&gt; This confuses me since creating those linkto files seems to<br>&gt; be unnecessary, at least for files whose hash values do not belong<br>&gt; to the subvol. (My understanding is that if a file's hash value is<br>&gt; in the range of a subvol then it will be stored in that subvol.)<br><br>Can you check if a lookup of the file post rebalance clears up these <br>_stale_ linkto files?</div><div><br></div><div>[paul:] No. Those linkto files are still there after I run "file /mnt/sbin/*".<br><div style="line-height: 21px;"><br></div>How did you compute the hash of these files and decide that they do not <br>belong to the new brick (i.e brick2)? I did them on my end and you are <br>right (based on the layout you presented above), but I am curious as to <br>how you arrived at the same conclusion.</div><div><br></div><div>[paul:]</div><div><div style="line-height: 21px;"><span style="line-height: 1.5;">The hash calculating script comes from</span></div><div style="line-height: 21px;">http://joejulian.name/blog/dht-misses-are-expensive/</div><div style="line-height: 21px;">It uses language binding by calling gf_dm_hashfn() in the</div><div style="line-height: 21px;">glusterfs C code finally. I added debug code in glusterfs</div><div style="line-height: 21px;">and double-confirmed that the script works correctly.</div><div style="line-height: 21px;">See more analysis below,</div><div>[root@lab1 ~]# ls -l /brick2/sbin</div><div>....</div><div><span style="line-height: 1.5;"><div>-rwxr-xr-x 2 root root &nbsp; 16576 Sep 12 11:26 wipefs</div><div>---------T 2 root root &nbsp; &nbsp; &nbsp; 0 Sep 12 11:27 xfsdump</div><div><div>[root@lab1 ~]# ./gethash.py xfsdump</div><div>0xc17ff86bL</div><div>[root@lab1 ~]# ./gethash.py wipefs</div><div>0x6afa24a9L</div></div><div><span style="line-height: 1.5;">[root@lab1 ~]# getfattr -dm. -e hex /brick2/sbin</span></div></span></div></div><div><div>getfattr: Removing leading '/' from absolute path names</div><div># file: brick2/sbin</div><div>trusted.gfid=0xddd06defaf1242b4b8ec5d41fdaa01e3</div><div>trusted.glusterfs.dht=0x00000001000000007fffffffffffffff</div><div><br></div><div>[paul:] It means that wipefs belongs to /brick1/sbin</div><div>and xfsdump belongs to /brick2/sbin, but under /brick2/sbin,</div><div>wipefs is migrated and xfsdump is linkto-ed. This does not</div><div>make sense. Or I did something wrong?</div><div>This is another issue besides the uncesessary linkto file issue.</div><div><br></div>Rebalance could choose to not move files but just create the linkto <br>files based on space usage between the source and target bricks etc. Not <br>stating this is what happened here, but a possibility.</div><div><br></div><div>[paul:] All the bricks are empty before testing. They are virtual disk partitions</div><div>in virtualbox centos 6.5 guests.<br><br>&gt;<br>&gt; I quickly looked at the code. gf_defrag_start_crawl() appears to<br>&gt; be the function for this operation. I do see code that does file migration<br>&gt; from the code path, but debugging code shows that those "linkto" files<br>&gt; seem to be not created by gf_defrag_start_crawl(). I'm not that familar with<br>&gt; the code detail and the theory so I'm not sure who created those<br>&gt; "linkto" files and why the "linkto" file are created.<br><br>I am going to leave this part as, dht_linkfile_create does this and <br>mostly would happen during lookup.</div><div><br></div><div>[paul:] I added debug code in dht_linkfile_create(). It appears that</div><div>it is called<span style="line-height: 1.5;">&nbsp;for those migrated files only.</span></div>