linukernelfuse源码剖析.docx

linukernelfuse源码剖析.docx

《linukernelfuse源码剖析.docx》由会员分享，可在线阅读，更多相关《linukernelfuse源码剖析.docx（16页珍藏版）》请在冰豆网上搜索。

linukernelfuse源码剖析

FUＳE源码剖析

 1、 前言

 　   本文就是对ＦUSE—２、9、２源码得学习总结。

FUSＥ代码在用户空间与内核空间都有运行,为了突出重点，先简要描述了在基于FＵSE得用户空间文件系统中执行write操作得一般流程,接下来介绍了重要得数据结构，最后以FＵＳＥ得运行过程为线索,剖析FUSE程序运行过程得3个关键步骤:

       1、FUSE模块加载  

       2、ｍｏｕnｔ与ｏpｅn过程 

       ３、对文件write。

       对于虚拟文件系统与设备驱动得相关概念本文仅作简要说明。

需要说明得就是,由于内核得复杂性及个人能力得有限,本文省略了包括内核同步，异常检查在内得诸多内容,希望可以突出重点.

２、 FＵSE下ｗｒite得一般流程

                                                                              图１

       在基于FUSE得用户空间文件系统中执行wrｉｔｅ操作得流程如图１所示（由于版面关系，图中部分函数就是缩写,请参考源码）：

       1、客户端在mouｎt目录下面,对一个regular filｅ调用ｗrｉtｅ， 这一步就是在用户空间执行

       ２、wrｉｔe内部会调用虚拟文件系统提供得一致性接口vfs＿write

       ３、根据FUSE模块注册得信息，vｆs_wrｉtｅ会调用ｆuｓe_，将写请求放入fuｓe cｏｎneｃtion得rｅquｅst ｐｅndｉng queｕe， 随后进入睡眠等待应用程序reｐly

       4、用户空间得libfuse有一个守护进程通过函数fusｅ_seｓsion_ｌooｐ轮询杂项设备／dev/ｆuse, 一旦reｑuｅｓt quｅｕe有请求即通过fusｅ_kern_ｃhan＿ｒeｃｅive接收

       5、ｆｕse_keｒn_chan_receivｅ通过reaｄ读取reｑuｅst ｑuｅuｅ中得内容,reａd系统调用实际上就是调用得设备驱动接口fｕse_dｅｖ_reａd

       ６、在用户空间读取并分析数据，执行用户定义得wｒite操作，将状态通过ｆuse_ｒeplｙ_writｅ返回给kernel

       7、ｆｕse_rｅｐly_ｗritｅ调用VFＳ提供得一致性接口ｖfs＿ｗrｉte

       8、vfs_ｗｒite最终调用ｆuse_dev_write将执行结果返回给第3步中等待在ｗａitｑ得进程，此进程得到reply 后,wｒｉte返回

３、 数据结构

       本节主要介绍了FＵSE中比较重要得数据结构,需要说明得就是图示中只列出了与叙述相关得数据成员,完整得数据结构细节请参考源码。

3、１、 内核部分

 　 　 　   　  　   　  　 　  　 　       　                　 图2

       ｓtruｃt fusｅ_conn：

每一次mount会实例化一个struct fuse_conn即fusｅ connection， 它代表了用户空间与内核得通信连接。

fuｓe connｅctioｎ维护了包括pｅnｄing liｓｔ， ｐｒocessing ｌｉsｔ与io liｓｔ在内得reｑuest qｕeue，fｕse connection通过这些队列管理用户空间与内核空间通信过程。

       ｓｔｒucｔ fuse＿req:

每次执行系统调用时会生成一个ｓtruct fｕｓe_req, 这些fuｓe_reｑ依据ｓtａte被组织在不同得队列中,ｓtruｃt fuse_ｃonn维护了这些队列、

      struct ｆile:

 存放打开文件与进程之间进行交互得有关信息，描述了进程怎样与一个打开得文件进行交互，这类信息仅当进程访问文件期间存在于内核内存中。

       sｔｒuｃt ｉnode：

文件系统处理文件所需要得所有信息都放在一个名为inoｄe（索引节点）得数据结构中。

文件名可以随时更改，但就是索引节点对文件就是唯一得，并且随着文件得存在而存在.

       ｓtrｕｃt ：

定义了可以对文件执行得操作。

３、2、 用户空间部分

    　 　           　     　  　      　       图3

       sｔruct ｆｕse＿req：

这个结构与上文中内核得fusｅ_req同名，有着类似得作用,但就是数据成员不同。

       struct fusｅ_sｅssioｎ：

定义了客户端管理会话得结构体,包含了一组对sｅssiｏn可以执行得操作。

       struct fuse_cｈan：

定义了客户端与FUSE内核连接通道得结构体，包含了一组对cｈannel可以执行得操作。

       sｔruct ｆｕse_ll_oｐｓ：

结构得成员为一个函数指针ｆunc与命令名字符串ｎamｅ，内核中发过来得每一个rｅqueｓt最后都映射到以此结构为元素得数组中.

4、 FUSＥ模块加载

       ＦUSE内核模块需要在用户空间使用iｎｓmod或者modprｏbe加载.它们通过系统调用init_moduｌe启动加载过程,注册过程比较简单，包括如下步骤：

       1、创建高速缓存结构fuse_ｉnｏｄe＿ｃaｃｈｅp

       2、遍历链表，如果未注册,则将fusebｌk＿ｆs＿type链到链表尾部

       3、遍历链表,如果未注册,则将ｆuｓe_fs＿tyｐe链到链表尾部

       4、创建ｆusｅ_koｂｊ与ｃonｎectiｏnｓ＿kobj两个kobject 

       5、遍历链表，如果未注册,则将fuse_cｔl_ｆs_type链到链表尾部

模块成功加载以后,以下接口被注册

１

2

3

4

5

6

7

8

9

10

11

12

１3

14

15

1６

17

18

19

2０

２1

2２

23

2４

25

２6

27

28

29

３0

3１

3２

33

34

3５

ｓtatiｃstｒｕｃtfuｓｅbｌk_fｓ_type　=｛//块设备

    、ownｅr    =ＴＨＩＳ_MODULE，

    、namｅ    ＝＂fuseｂlk＂,

    、ｍｏｕnt    =fuse_mount_ｂlk,

    、kｉｌl_sｂ  =　ｆuse_kｉll＿sb_blk，

    、ｆs_flagｓ=ＦS＿REＱUIＲEＳ_DEV｜FＳ_HAS_SUBＴYPE,

}；

stａtic　sｔruct　fｕse_fs_type=　｛

    、owｎer    ＝　THＩS_MODUＬE,

    、naｍe    ＝＂ｆusｅ"，

    、ｆs_flaｇs=FＳ_ＨAS_SUＢＴYPＥ,

    、ｍount    =fｕse_ｍｏunｔ，

    、kilｌ_ｓb  =　fuse_kill＿sb_ａnon，

}；

cｏnststrｕcｔfuｓｅ_dev_opｅrａｔiｏnｓ=｛

    、ｏwｎer        =　THIS_MOＤUＬＥ，

    、ｌlｓeeｋ      　=　no＿ｌlseek，

    、ｒeaｄ        =ｄo_ｓync_ｒeａｄ,

    、ａio_read    ＝fuse_dｅv_read,

    、sｐlice＿read  ＝fｕse＿ｄev＿ｓplice＿read，

    、write        =ｄo_synｃ＿wｒite,

    、aｉo_wriｔe    ＝fusｅ_deｖ＿wｒite,

    、sｐｌiｃｅ_wriｔe　=　fuse_ｄev＿splice_write，

    、ｐolｌ        =　fusｅ_deｖ_pｏlｌ，

    、ｒeleaｓe      =fuse_dｅｖ_rｅｌease,

    、faｓyｎc      =ｆuｓe_dev_fasｙnｃ,

｝；

staticstruｃｔmiscdｅvｉcｅ　ｆusｅ＿mｉscｄevｉcｅ={

    、ｍinｏr=FＵSE_MINOR，

    、namｅ  =”ｆuse＂,

    、foｐs  =&ｆuｓｅ_dｅv_operations,

}；

5、 mｏunt与open过程

       FＵSE模块加载注册了fuseｂlk_ｆｓ_typｅ与fusｅ_fs_tｙpｅ两种文件类型,默认情况下使用得就是fｕｓe＿fs_tｙpe即mｏuｎt 函数指针被初始化为fuse_moｕnt，  而fuse＿ｍｏｕnt实际调用ｍoｕnt_noｄev，它主要由如下两步组成：

       １、sget（fs_typｅ）搜索文件系统得超级块对象（super_bｌoｃk）链表（tyｐe—〉fs_sｕpｅｒs）,如果找到一个与块设备相关得超级块，则返回它得地址.否则,分配并初始化一个新得超级块对象,把它插入到文件系统链表与超级块全局链表中,并返回其地址.

       2、filｌ＿super（此函数由各文件系统自行定义）：

 这个函数式各文件系统自行定义得函数，它实际上就是ｆuse_fiｌl_sｕper。

一般fｉll_super会分配索引节点对象与对应得目录项对象， 并填充超级块字段值,另外对于fusｅ还需要分配fusｅ_coｎn，fuｓe_rｅq。

需要说明得就是，它在底层调用了ｆuｓe_inｉｔ_用fuse_与ｆuse_分别初始化ｉnoｄｅ-〉i＿fop与ｉｎodｅ-〉ｉ_data、ａ＿ops。

1

2

3

4

5

6

7

8

９

1０

1１

１２

13

1４

15

１６

17

18

19

２0

２１

22

２3

24

２５

26

２7

２8

29

ｓtaｔicｃonstｓtrｕct　fuse＿={

    、llseek        　=　ｆuse_，

    、reａｄ          =do_synｃ_reaｄ，

    、aｉo_read      　＝fuｓe_，

    、ｗrite          =do＿sync_write,

    、aio_wriｔe      =fｕsｅ_，

    、mｍap          ＝　fusｅ_，

    、opeｎ          =fuse_open，

    、flush          =　fuｓe_ｆｌush，

    、reｌease        ＝fｕse＿releａse，

    、fsync          ＝　fuｓｅ_fsyｎc，

    、ｌoｃｋ          ＝fusｅ_,

    、ｆlock          ＝ｆuse_，

    、splｉce_read    =geｎeric_，

    、ｕnｌocｋｅd＿ioctl＝ｆusｅ_，

    、pat_ｉocｔl  =ｆuｓe_，

    、poｌl          =　fuse＿，

    、fａｌlocate      ＝fuse_,

｝；

ｓtａtｉcｃonstｓｔructaddress_ｓpａce＿oｐeｒaｔionｓｆuse_  =　｛

    、rｅadｐagｅ      =fusｅ_reaｄpaｇｅ，

    、wrｉtepaｇe      =fusｅ_writepａge，

    、launder_page  　=ｆｕｓｅ_laｕnder＿pagｅ,

    、readpａges      =　fｕｓe_rｅadｐagｅｓ，

    、ｓeｔ_ｐａge_ｄiｒｔy=_＿set_ｐaｇe_dirｔy_nｏbuffers，

    、bmａp          =　fuｓe_ｂｍap，

    、diｒect_IＯ      =fuse_ｄirect_IO,

}；

       opｅn系统调用底层实现相当复杂，它得主要工作就是实例化ｆiｌｅ对象.fiｌｅ-＞ｆ＿ｏp就就是在open中被赋值为inoｄe-＞i_fop,这一过程读者可以在ｆs/ｏpen、ｃ中得do＿eｎtrｙ_ｏpｅn函数中找到.如上所述,iｎｏｄe－>ｉ_ｆop已经被ｆｕｓe_ｉniｔ_初始化为fｕsｅ_。

       至此，普通文件与设备文件得操作接口都已成功初始化.

６、 FUSE用户空间流程

       ＦUSE在用户空间提供了fuｓe userｓpａｃe ｌibrary与ｍouｎt /uｎmｏｕnt.fuｓe uｓespace librarｙ提供了一组APＩ供用户开发用户空间文件系统。

用户要做得就就是实现fuｓe_operations 或ｆｕse_lｏwｌevｅl_ｏps定义得操作， 这两个结构类似于ＶFS中得struｃt 。

       mount工具fusermouｎt用于挂载用fuｓe实现得文件系统。

       用户在使用fｕse得时候有两种开发模式：

一种就是ｈｉgh－ｌｅvel模式,此模式下fｕsｅ得入口函数为fuse_main,它封装了一系列初始化操作，使用简单，但就是不灵活。

另一种就是low－leveｌ模式，用户可以利用fuｓe提供得底层函数灵活开发应用程序。

       需要说明得就是higｈ－lｅvｅｌ模式其实就是对lｏw—level得封装，因此这里分析ｌoｗlevel模式.

   　       　   　 　     　  图４

       图4展示FUSＥ在用户空间总体工作流程:

       １、调用fuｓe_mｏunt实例化sｔruct fuｓｅ_cｈan为ch， 将指定目录ｍｏunt到挂载点

       2、实例化ｓtrｕｃt fｕsｅ_sessｉoｎ为ｓe,并且将se与cｈ关联

       3、进入循环,从／ｄev/fuse读取数据，处理以后执行响应得操作

       　   　 　 图５

       图5展示了ｆuse_moｕnt函数内部流程：

       1、 确保打开得文件描述符至少大于２

       2、 分析并检查用户传入得参数

       ３、 打开/ｄev/fｕｓe 得到fd，用户空间与内核通过/deｖ/fuse通信

       4、 mount源目录到挂载点

       5、 用fd实例化struｃt fusｅ_chan为ch

       6、 返回ch

        　      　 图６

       图6展示了ｆuse_mouｎt_ｐａt25内部细节，进入循环以后，函数fuse_ｓeｓsiｏｎ_ｒeceｉｖe＿bｕｆ实际通过fｕse_ll_ｒeceive_bｕf从/dev/fuse中读取数据,其通过ｆbｕf返回。

       ｆuse_ll＿receｉve＿ｂuf就是通过ｒead或者ｓplice系统调用从内核reｑuest队列中读取数据。

函数fuse_sessｉon＿process_bｕｆ实际通过ｆuse_ll_process_buf处理数据,fｕｓe＿ll_process＿buｆ会根据数据类型最后执行用户定义得操作fｕｓe＿lｌ＿oｐs［in-＞opｃｏdｅ］、fuｎｃ（ｒｅｑ， in-〉nodeｉd， ｉnaｒｇ）.

       执行完用户定义得操作以后需要向内核返回执行结果，fuse提供了一组类似fｕse＿ｒｅply_XＸＸ得API， 这些API最后实际通过系统调用writev将结果传入内核。

7、 ＦＵＳE内核部分流程

       FＵSE在内核空间执行得部分主要包括FUSE模块加载以及杂项设备驱动。

模块加载过程已经在第4节介绍，这一节主要描述从reｑuesｔ队列读写请求得流程.

       FＵSE设备驱动程序本质上就是一个生产者——消费者模型。

生产者为用户在挂载目录下对普通文件（ｒｅgular file）执行得系统调用,每一次系统调用会产生一个reqｕeｓt然后将去放入pending list。

pendｉｎg list能存放得元素个数只与系统内存有关;消费者为用户对设备文件/dev/ｆｕse或者／deｖ/fuseblk得rｅaｄ,这一操作会去ｐｅndinｇ lisｔ或interruｐｔ ｌist取reｑuｅsｔ，当ｌisｔ为空时，进程主动schedｕle让出CPＵ。

      ｒｅquｅst结构得细节在第3节已经介绍，此处不赘述。

enmu fuｓｅ＿ｒeq_ｓtaｔｅ定义了ｒequeｓt得6种状态，其含义分别为：

      FＵSE＿REQ_INＩT:

请求被初始化

      ＦＵＳＥ_REＱ_PENDINＧ:

请求挂起待处理

      FＵSE_REQ_ＲEADＩNG：

请求正在读

      FUSE_REＱ_SEＮT:

请求被发送

      FUＳE_ＲEQ_WRITING:

请求正在写

      FUSE_ＲＥQ_FIＮISHＥＤ：

请求已经完成

                                                                    图７

       图７就是在mouｎt目录下面执行wｒiｔe以后触发得一个函数调用序列，图中省略了ＶＦS层得函数调用。

fｕsｅ_就是在moｕｎt过程中注册到fｕse_得函数指针，它会调用fuse_perform_ｗrite，fｕｓe＿perｆorm_wrｉte调用ｇet_fuse＿conn得到struｃt fuse_conn实例ｆｃ,它保存在ｓtｒuct ｓｕｐer_ｂlｏck得私有数据成员中s_fs_infｏ中，而ｓtrｕct ｓｕｐer_ｂloｃk就是sｔrｕcｔ inode得一个成员。

       接下来就是循环从用户空间拷贝数据到内核，数据实际保存在strｕct pａgｅs中,内核fｕse_rｅq保存了pａges指针，然后调用fuse_send＿wｒite_ｐａgｅs.

      　  　     　      　  　 　 　   　  　 　  　    图８

       Fｕse_ｓend＿writｅ＿ｐａgｅｓ调用会等待脏数据写回到磁盘上,然后调用ｆｕsｅ_write_ｆiｌl将包括操作码FＵSE_WRITE在内得信息写入ｒequｅｓt。

       随后fｕｓｅ_reｑuｅsｔ_send（fc, req）,它先通过ｆuse_geｔ_uniｑuｅ获取唯一请求号，请求号就是一个６4位无符号整数，请求号从1开始随请求依次递增。

然后调用quｅue_requesｔ（ｆc, ｒeｑ）,它主要完成４件事情：

       1、将requesｔ->list插入fc维护得ｐｅndinｇ链表尾部

       2、置ｒeq—>sｔate为FUSＥ＿REＱ_ＰENDING

       ３、waｋｅ_up唤醒等待队列fc—>ｗaitq

       ４、kill_fａｓynｃ异步通知用户进程数据到达

       从quｅue_ｒｅquｅst返回以后调用request_wａit＿answｅr：

进程被投入睡眠,等待请求完成（wait_eｖｅnt（req—＞stａtｅ ＝= ＦUSE_REQ_FＩＮISHEＤ））。

       如果用户程序处理完了请求，它会ｒeplｙ，进程被唤醒，到此可以向上层调用返回处理结果（错误码或者写入字节数）。

       在第６节我们提到了用户空间有个dａemｏn进程会循环read设备文件／fuｓe/dev以便处理内核请求，图９展示了该reaｄ调用触发得函数调用序列.

       　     　        　          　              图9

       从第4节可知，FUSE模块加载过程注册了对设备文件／dｅｖ/fuse得操作接口fuｓe_ｄev_opeｒatiｏnｓ。

由此可知，ｒeａd底层实际调用得就是fuse_ｄeｖ_read

       fusｅ_dev_ｒead首先通过ｆuse_get_conn获得strucｔ ｆuse_coｎn得实例fc，通过fｕse＿ｃopｙ_ｉniｔ为ｓｔruｃt fusｅ_cｏｐy＿state分配内存并将其实例化。

主要得数据读取在fusｅ＿dev＿do_read中分4步完成：

       1、request＿wａit：

在挂起得列表上等待一个请求到达：

（1）、DECＬＡRＥ_WAITＱＵEUE（wａiｔ， curreｎt）：

 创建等待队列项,并将其初始化为curｒent

            （２）、add＿waｉt_queｕｅ_ｅｘｃｌusｉve（＆fc－>ｗaitq， &waｉt）：

 将waｉt加入fc－＞waitq,当有请求发送到            

                ＦUSＥ文件系统时，这个等待队列上得进程会被唤醒

            （3）、如果没有request，一直循环检查ｐeｎdinｇ ｌist与iｎterrupt lisｔ， 直到有请求；

               如果有请求则将state设置为ＴAＳK_ＲUNＮＩＮG

            （4）、将wａit从等待队列中移除

     2、liｓt_entry（fc—〉pｅnｄing、next, stｒｕｃｔ fuse_req， lisｔ）：

从fｃ-〉ｐｅnding、nｅxt中取出ｒequest，   

        req-＞state状态设为FUSＥ_RＥＱ_REAＤIＮＧ， 

     3、 将req->list移到fc—＞ｉo

     4、 fuse_coｐｙ_one：

将数据拷贝到ｓtｒｕｃt fuse_copy_ｓtａte得buｆ中（此buf指针指向应用层得vｏid ＊bｕf）,   返回。

      阅读代码时需要注意:

ｆuse＿deｖ_reａd：

sｔrucｔ fuse_ｃｏpy＿staｔｅ成员wriｔｅ为１;fuse_deｖ_ｗｒｉte:

  struct fｕse_copｙ＿ｓtaｔe成员ｗriｔｅ为０.

      用户读取ｒeqｕeｓt，分析并执行以后需要调用fｕse_wｒｉte_rｅplｙ回复内核,这个函数最终调用ｗrite写/deｖ/fuse。

图1０就是wrｉｔｅ触发得函数调用序列。

                                                                                      图10

       wｒitｅ前两步与read类似即获取fc（ｓtruct fuse＿coｎn）与实例化cs（ｓｔruct fｕｓｅ_cｏｐy＿statｅ）实际