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有缓存则直接从缓冲中获取，否则从对象存储中重新获取，并进行缓存。
标签：数据服务,文件,存储,slice,读写,key,JuiceFS,解析,inode 来源： https://www.cnblogs.com/luohaixian/p/15374849.html