[Gluster-devel] Feature support: development of metadata service xlator plugin in glusterfs.

[张兵]

Thank you for your reply.
In glusterfs,Some metadata information is recorded in the file's extended attr in all
bricks,
For example EC volume, N+M mode, stat file requires N+M command,
file write, requires M+M lock, record file length, and also N+M setattr command,
Finally n+m unlock command;
if have metadataserver,All metadata related operations
only one command to metadata server;
As the old topic, MKDIR requires that all the DHT children should be executed Mkdir;
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;
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;
How to solve these difficulties.













At 2015-06-21 05:31:58, "Vijay Bellur" <vbellur at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150621/46d5ff72/attachment.html>