C/C++教程

JuiceFS框架介绍和读写流程解析

本文主要是介绍JuiceFS框架介绍和读写流程解析,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

1.基本组件介绍

  

JuiceFS Client:支持多种Client端的接口,比如兼容POSIX文件系统的接口,以此你可以将它挂载到系统上当文件系统使用,且可以为k8s提供存储使用,用ks8s的csi driver进行接入。同时也支持S3协议,开发了对应的S3网关进行支持;

Data Storage:对象存储服务,用以存储具体数据的,可以类比文件系统里的block数据保存,支持多种后端存储;

Metadata Engine:元数据服务,用以存储文件元数据信息的,比如文件名、目录信息、文件inode等信息,可以类比文件系统里的inode数据管理,支持多种元数据存储;

 

2.快速部署

我们使用docker部署一个minio作为对象存储服务,用docker部署一个redis作为元数据服务。

git下载juicefs代码并进行编译生成juicefs二进制可执行文件:

git clone https://github.com/juicedata/juicefs.git

cd juicefs && make

 

安装docker和下载redis和minio/minio镜像。

 

部署元数据服务和对象存储服务:

sudo docker run -d --name redis -v /data/redis-data:/data -p 6379:6379 --restart unless-stopped redis redis-server --appendonly yes
sudo docker run -d --name minio -v /data/minio-data:/data -p 9000:9000 --restart unless-stopped minio/minio server /data

 

进行format和挂载:

mkdir /data/ussfs

./juicefs format --storage minio --bucket http://127.0.0.1:9000/test123 --access-key minioadmin --secret-key minioadmin redis://127.0.0.1:6379/10 test123
./juicefs mount -d redis://127.0.0.1:6379/10 /data/ussfs

 

3.挂载过程分析

format过程:

format的作用是将一些元数据信息先注册好,在mount时进行获取作为配置参数,比如对象存储的相关信息,bucket的相关信息等。

 

流程说明:

(1)接收客户端执行的命令,如果是mount的命令,则进入mount逻辑;

(2)通过format给定的url来判断是哪种元数据服务,并初始化元数据服务对象;

(3)构建format结构体对象,结构体里包含对象存储服务信息,block size等信息;

(4)根据format的信息初始化对象存储服务并测试对象存储服务是否可增删改操作,确保对象存储服务可用;

(5)持久化format信息,在redis为元数据服务时,即是将格式化后的format数据保存到redis的setting这个key中;

(6)创建inode号为1的第一个文件,文件类型为目录,作为后续创建文件的父目录,并持久化到元数据中。

 

mount过程:

mount就是将自定义的文件系统挂载到指定目录下,可供符合POSIX的接口进行调用,由mount中开启的server服务进行文件操作请求接收并处理。

  

流程说明:

(1)获取mount中的命令行参数,获取到元数据信息url;

(2)创建元数据服务连接实例,从元数据服务中获取之前保存的format信息;

(3)根据format信息创建对象存储服务连接实例storage,创建store对象,store对象是对对象存储数据进行管理,store对象属性里包含了storage对象和对cache的管理;

(4)初始化vfs对象,vfs是一层虚拟文件系统对象,它包含了对meta和storage的管理,创建了读写对象和文件句柄管理;

(5)如果命令行参数中是有用-d指定了mount进程后台运行,则调用makeDaemon函数将fork出一个进程作为daemon进程后台运行;

(6)通过读取挂载目录文件属性来检查挂载目录是否可进行挂载;

(7)创建本次挂载session,生成session信息保存到元数据服务中;

(8)创建自定义的文件系统类型,通过用户态fuse(用户空间实现文件系统)库来进行实现,启动服务来接收fuse的请求信息并封装成request,解析request找到对应的处理函数进行处理并返回。

 

启动的server接收fuse请求大致流程图:

 

4.元数据保存key含义解析

主要介绍在redis为元数据服务时,保存的各个key的含义,方便下面讲解读写流程。

这里我们先列出redis中保存的所有key:

 

可以看到,大概分成好几种key,有i开头的,有d开头的,有c开头的,还有其它的一些固定字符串的key。

setting:保存的format信息的key,对应的结构体:

type Format struct {
    Name        string
    UUID        string
    Storage     string
    Bucket      string
    AccessKey   string
    SecretKey   string `json:",omitempty"`
    BlockSize   int
    Compression string
    Shards      int
    Partitions  int
    Capacity    uint64
    Inodes      uint64
    EncryptKey  string `json:",omitempty"`
}

 

i1:表示记录的inode号为1的文件的属性信息,同理i2为inode号为2的文件属性key,保存的值对应的结构体为:

// Attr represents attributes of a node.
type Attr struct {
    Flags     uint8  // reserved flags
    Typ       uint8  // type of a node
    Mode      uint16 // permission mode
    Uid       uint32 // owner id
    Gid       uint32 // group id of owner
    Atime     int64  // last access time
    Mtime     int64  // last modified time
    Ctime     int64  // last change time for meta
    Atimensec uint32 // nanosecond part of atime
    Mtimensec uint32 // nanosecond part of mtime
    Ctimensec uint32 // nanosecond part of ctime
    Nlink     uint32 // number of links (sub-directories or hardlinks)
    Length    uint64 // length of regular file
    Rdev      uint32 // device number
 
    Parent    Ino  // inode of parent, only for Directory
    Full      bool // the attributes are completed or not
    KeepCache bool // whether to keep the cached page or not
}

 

d1:当文件为目录类型时,就会对应一个d开头的key,1表示该文件夹是inode号为1的,它是一个hash类型的键,它的每个field key是文件名字,field key对应的值是文件类型和对应的inode号,field key的值保存着文件类型和文件inode号。这样的话就可以方便的找到某个目录下的某个文件名的inode号及该文件的类型,同理d3就是inode号为3的文件夹记录着它文件夹下的文件元信息。

 

c14_0:c表示chunk的意思,我们先来看下这个数据结构图

 

可以看到一个文件数据会被拆分成chunk来进行保存的,如果是大文件,那么会被按指定大小拆分成多个chunk,这个c14的14就表示这个chunk是归属于inode14这个文件的,c14_0的0则表示是第一个chunk,该key是列表类型的键,它的每个元素是一个slice,slice不是固定大小的,slice会根据block size大小拆分成多个block进行存储,比如block size是4M,如果slice是6M,则拆分成2个block来进行存储,计算出对应的两个key把键值往对象存储服务中存储。比如生成35_0_16384和35_1_8192,35是表示这个slice的id(Slice结构体中的Chunkid字段),0和1表示两个block,16384和8192分别表示block的大小,分别为4M和2M。

chunk的结构体:是slices列表的数据结构,[]meta.Slice

Slice结构体:

// Slice is a slice of a chunk.
// Multiple slices could be combined together as a chunk.
type Slice struct {
    Chunkid uint64
    Size    uint32
    Off     uint32
    Len     uint32
}

 

nextinode:它是一个自增的key,作用是分配新的inode;

nextchunk:它也是自增的,用来分配给slice的chunkid的;

nextsession:它也是自增的,用来给session结构体分配session id的。

totalInodes和usedSpace是记录当前一共有多少个inode和当前空间已使用量的。

 

5.读写文件过程分析

5.1.创建文件夹

创建文件夹命令示例:mkdir /data/ussfs/testdir

流程图:

 

流程说明:

(1)先获取根文件属性信息,然后通过文件路径和文件名获取指定文件属性,获取的方式就是一层层获取,比如/a/b/c,先是在a目录下找b,然后在b目录下找c,这是通过调用doLookup函数来查询获取;

(2)如果要创建的文件夹不存在则进行创建,创建调用doMkdir函数进行创建,该函数又调用mknode函数来创建文件信息(文件夹也是一个文件);

(3)从元数据服务器中获取一个新的inode号,如果是redis元数据服务,则是由一个自增的nextinode来保存当前分配的inode号;

(4)设置新文件的文件属性信息,比如权限、创建时间等信息;

(5)向父目录中添加该新文件,当redis为元数据服务时,则是向d开头的key里比如d1里添加一条该新文件信息;

(6)更新父目录文件属性信息、新文件属性信息和文件系统的一些总体使用信息。

 

创建文件跟创建文件夹类似,先调用的doCreate,然后也会调用mknode来生成inode和保存文件属性信息。

 

5.2.写入数据到文件

写入文件命令示例:echo "123456789" > /data/ussfs/testdir/testfile

流程图:

 

流程说明:

(1)跟先前类似,先通过文件路径找到该文件,获取该文件属性信息,如果文件不存在先创建文件;

(2)调用doopen函数打开文件,主要是初始化文件handle,创建文件读写对象,返回文件描述符;

(3)调用dowrite,传入偏移位置和写入数据,通过偏移位置计算出要写入到第几个chunk中去,如果是跨chunk(一个chunk默认64M),则先写入一部分数据到一个chunk,然后再写剩下的数据到下一个chunk;

(4)在一个chunk中查找合适的slice进行写入,比如改变的数据是在中间部分的,那其实只要更新那一个slice数据即可,其它slice可以不变更,我们目前这场景是找不到一个合适的slice,它会创建一个slice,然后通过该slice进行数据上传;

(5)通过偏移量进行block的计算,每个block会生成对应的key,然后调用对象存储的put方法进行key value的上传来存储数据;

(6)保存slice元信息到元数据服务中。

 

5.3.读取文件数据

读取文件命令示例:cat /data/ussfs/testdir/testfile

流程图:

 

流程说明:

(1)跟先前类似,先通过文件路径找到该文件,获取该文件属性信息,如果文件不存在先创建文件;

(2)调用doopen函数打开文件,主要是初始化文件handle,创建文件读写对象,返回文件描述符;

(3)分配存储数据的page数据结构,从元数据服务获取所有slice列表;

(4)遍历每个slice,取出slice对应的所有block信息保存到page对象中;

(5)如果block有缓存则直接从缓冲中获取,否则从对象存储中重新获取,并进行缓存。

 

这篇关于JuiceFS框架介绍和读写流程解析的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!