<div dir="ltr"><div dir="ltr">Hi Joe</div><div dir="ltr"><br></div><div>Thanks for your kindly response</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 6:38 PM Joe Thornber <<a href="mailto:thornber@redhat.com">thornber@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 05, 2019 at 02:43:28PM +0800, jianchao wang wrote:<br>
> But why does it use this 4K page instead of btree as the disk sm ?<br>
> <br>
> The brb mechanism seem be able to avoid the nested block allocation<br>
> when do COW on the metadata sm btree.<br>
> <br>
> Would anyone please help to tell why does it use this 4K page instead of a<br>
> btree ?<br>
<br>
It's a long time since I wrote this, so I can't remember the order that things<br>
were written.  It may well be that brb mechanism for avoiding recursive allocations<br>
came after the on disk formats were defined.  Irrespective of that the single page<br>
pointing to index pages should perform better.<br>
<br>
Is the 16G limit to the metadata device causing you issues?<br></blockquote><div><br></div><div>Yes, we are planing to build a 200T pool at least and there are both normal thin device</div><div>and snapshot running on it.  Smaller block size would be better, but 16G is not enough.</div><div><br></div><div>Actually, I have modified the metadata sm code to use btree as the disk sm. In my test</div><div>environment, I have used ~20G metadata.</div><div> </div><div>Thanks</div><div>Jianchao</div></div></div>