<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><div><div>Thank you for your reply.<br>In glusterfs,Some metadata information is recorded in the file's extended attr in all </div><div>bricks,<br>For example EC volume, N+M mode, stat file requires N+M command,<br>file write, requires M+M lock, record file length, and also N+M setattr command,<br>Finally n+m unlock command;<br>if have metadataserver,All metadata related operations<br>only one command to metadata server;<br>As the old topic, MKDIR requires that all the DHT children should be executed Mkdir;<br>Another difficult problem, lack of centralized metadata; disk recovery performance is not able to get a massive upgrade;Such as EC N+M volume, disk reconstruction, and only bricks n+m to participate in the reconstruction;Rebuilding 1TB takes several hours;<br>The use of metadata, the data can be dispersed to all the disk,Disk failure, a lot of disk can be involved in the reconstruction;<br>How to solve these difficulties.<br><br><br><br></div><div style="position: relative; zoom: 1;"></div><div id="divNeteaseMailCard"></div><div><br><br><br><br><br></div></div><div style="position: relative; zoom: 1;"></div><div id="divNeteaseMailCard"></div><div><br></div><pre><br>At 2015-06-21 05:31:58, "Vijay Bellur" <vbellur@redhat.com> wrote:
>On Friday 19 June 2015 10:43 PM, Õűø wrote:
>> Hi all
>> In the use of the glusterfs ,found file system commands a lot, such
>> as stat, lookup,setfattr, the very influence system performance,
>> especially with EC volume. The use of glusterfs code architecture and
>> add metadata server xlater and achieve similar GFS architecture; so, the
>> same set of software, users can choose their own metadata server or not
>> to choose the metadata server;
>
>How do you expect the metadata server to aide performance here? There
>would be network trips to the metadata servers to set/fetch necessary
>information. If the intention is to avoid the penalty of having to fetch
>information from disk, we have been investigating the possibility of
>loading md-cache as part of the brick process graph to avoid hitting the
>disk for repetitive fetch of attributes & extended attributes. I expect
>that to be mainlined soon.
>
>If you have other ideas on how a metadata server can improve
>performance, that would be interesting to know.
>
>Regards,
>Vijay
>
>
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>