深入理解Lustre文件系统-第4篇 LOV和OSC

从高层的图景看,LOV的任务是将页指向正确的OSC,而OSC的任务是收集脏页向量、组合(group)它们、将它们从传输线上发送到OST(当然,通过PortalRPC和LNET)。

4.1 OBD设备操作

OBD面向设备操作是一个在LOV、OSC和MDC中使用并能被看到的一般性的源码组织模式和实现方法。OBD设备由obd_ops结构体定义的方法表描述,该方法表有点类似于前面提到的VFS文件、索引节点、dentry操作。其中的思想是,你不需要确切知道你所正在处理的OBD设备,只需使用以OBD_开头的一般性封装方法。让我们来看一眼这个表所定义的方法:

struct struct obd_ops {

struct module * o_owner;

int (o_setup)(structobd_device *dev, obd_count len, void *data);

int (o_attach)(structobd_device *dev, obd_count len, void *data);

int (o_detach)(structobd_device *dev);

int (o_setattr)(structobd_export *exp, struct obd_info *oinfo ...);

...

}

虽然在该结构体中定义了超过70个方法,但是只支持其中的一小部分。所以,它已经失去了初始预想的一般性特质。但是,这个方法为我们提供了一个路线图,可以用来分析围绕特定OBD设备所进行的活动。

对于LOV,需要注意的另外一个事情是,它是解释分条信息的层;所以这里的一个文件操作往往会变成对一群对象的操作。

当LOV模块初始化时,它将它所支持的OBD设备注册为一个class类型的管理者。从本质上说,这种class类型管理者在一个flat空间中管理了一个class名字和与之相关的特性。

rc = class_register_type(&lov_obd_ops, lvars.module_vars,LUSTRE_LOV_NAME);

4.2 页管理

页管理是一个在多层间进行的活动。页高速缓存是内核维护的一个一般性内存空间。Lustre页是一些为Lustre系统所知的特殊页。在页描述符中的私有字段中,存储了其特有的性质。它被分成3部分:llap、lap和oap。相应的,对它们进行处理的层分别为:llite, lov和osc,如下图所示:

深入理解Lustre文件系统-第4篇 LOV和OSC

为了让我们讨论更实际,更有重点,我们将时不时地提及如下使用情形:一个用户空间的应用想创建文件A,然后向之写入6.5MB数据。分条大小为1MB,分条宽度为3,OST编号为OST1、OST2、OST3。文件A的数据对象称为A1、A2、A3。在这些OST上的其他文件称为B1、B2、B3和C1、C2、C3,如图5所示。现在,我们需要定义和澄清一些概念和数据结构。在VFS和Lustre Lite层,读写以页为单位进行——注意这并不影响通过Portal RPC和LNET传输的实际数据。

深入理解Lustre文件系统-第4篇 LOV和OSC

每页数据都需要在OST磁盘上的文件数据对象里找到自己归属。位置信息实际上是多元组(tuple)<OST索引, 以页单位的文件数据对象中的便宜,页中的偏移>。如下是其定义:

struct lov_async_page {

int lap_stripe; /* sameas OST logical index */

obd_id lap_loi_id; /*object id as seen by OST */

obd_off lap_sub_offset;/* offset within object in page-unit */

...

}

struct osc_async_page {

obd_off oap_obj_off; /*offset within object in page unit */

unsigned oap_page_off;/* offset within a page */

...

}

4.3 从OSC客户端到OST

为了与OST交互,客户端需要创建一个对应的OSC客户结构体client_obd。这是一个一对一映射。注意client_obd同时还代表MGC、MDC。所以,它非常一般化,其中的一些字段只有对于特定客户端才有意义。

每个由OST客户端进行处理的每个数据对象,都会创建一个lov_oinfo对象(loi),每个对象都描述了一个与OST对应的对象。每个lov_oinfo的读写都进一步链接到OAP页上。

lov_oinfo也链接回client_odb,所以它可以被用作搜索的起始点,用来搜索这个客户端所处理的所有对象各自对应的lov_oinfo,同时用来继续定位所有在写操作过程中缓存了的脏OAP页。

图6说明了两个OSC客户端和两个OST相互作用的情形。第一个OST存储了A1、B2、C3的数据对象,第二个OST存储了A2、B1。


深入理解Lustre文件系统-第4篇 LOV和OSC


4.4 Grant

每个客户端都缓冲了一些脏数据。当前,每个OSC的默认设置是32MB。考虑到我们系统中存在的客户端数量,容易得出当所有的客户端都刷新脏缓冲时,可能导致服务端耗尽文件系统空闲空间。为了避免这种情况的发生,服务端为每个客户端所能刷新和传输的量设立了一个确切的限制,称为grant。客户端能够请求更多,而服务器决定grant的增加量。它根据客户端缓冲的脏数据量进行调整。当grant变为0时,所有的I/O变为同步模式,直到客户端能够增加它的grant为止。

本文章欢迎转载,请保留原始博客链接http://blog.csdn.net/fsdev/article

你可能感兴趣的:(文件系统)