文件系统接口设计图(接口文件和实现文件)

网友投稿 524 2022-12-30


本篇文章给大家谈谈文件系统接口设计图,以及接口文件和实现文件对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 今天给各位分享文件系统接口设计图的知识,其中也会对接口文件和实现文件进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

架构设计:文件服务存储设计

在架构设计:文件服务的设计与实现一文中,通过实现一个文件服务来梳理文件系统接口设计图了一个架构设计的一般流程,并得到如下静态架构图

本文继续聊聊文件服务中的子模块:「存储模块」的设计,包括:

前面的架构没有对存储进行特别设计,直接使用了本地存储。考虑到后期文件数量可能会越来越多,本地存储可能无法支撑,且本地存储的安全性也没有保障。为了便于后期扩展,需要对「存储」部分进行设计。

存储的方式有很多,本地存储、NAS、分布式存储,为了能支持不同的存储方式,需要对「存储模块」进行抽象。考虑到「存储模块」涉及到IO,是一个相对底层的模块。「上传」这个核心模块不能依赖于具体的存储,所以这里也需要对其进行依赖反转。

见紫色部分,UploadService调用了FileInfoRepository来存储FileInfo,而FileInfoRepository是个接口,具体实现由存储模块中的实现类来实现。

我们先看本地存储。最简单的实现,就是直接使用IO将文件写到对应的目录下就可以了。但是,本地存储会有如下几个问题:

下面我们针对上面的问题,来一个个的解决。

首先,对于多租户来说,在我们的架构中,实际对应的是Group,我们按照Group的不同,来划分目录即可。即 不同的租户有不同的文件根目录 ,后期某个租户迁移时,直接迁移对应目录即可。这也稍微解决了单目录文件数量多的问题。

对于单目录下,随着文件数量的增加导致访问速度下降的问题,我们该如何解决呢?

如果文件系统接口设计图你做过分布式系统,那么想一想, 我们是否可以把单目录看成是一个服务器,访问目录下的文件看成是一个个的请求呢 ?如果可以,那解决单目录下访问速度慢的问题是不是就变成了「如何解决单服务器下,负载过高」的问题了?那解决服务端负载过高的方法是否适用于解决目录访问速度下降的问题呢?

我们从下面几个方面来分析一下:

首先来看「解决服务端负载过高的方法」!答案很明显: 分流+负载均衡 !

分布式服务的负载均衡有几种方式呢?

再来看「目录访问和服务器的区别」,虽然可以把目录看成服务器,但是两者还是有区别的:

也就是说,对于目录来说,我们不需要考虑创建成本。

那么针对服务器负载高的解决方案是否适合目录访问呢?或者哪种方式适合目录访问呢?我们一个个来分析:

可以看到,主要的问题就是创建目录的问题!如何保证在目录数量改变时,不需要调整程序呢?

实际上git已经给出了答案:

也就是说,根据sha1散列的前两位对文件进行归类。这样既解决了目录创建问题,也解决了文件分布问题。可能的问题是,「sha1散列2^80次,可能会发生一次碰撞」。这个问题对于一般文件系统来说,好像也没有担心的必要。

解决了「单目录文件过多,导致访问速度下降」的问题,我们来看下一个问题: 数据安全 。

文件数据是存放在电脑磁盘上的,如果硬盘损坏,可能导致文件的丢失。这实际还是一个「单点问题」!

「单点问题」的解决方案是什么呢? 冗余 啊!

最简单的方案就是定时去备份数据,可以有如下几种方案:

我们继续一个个的讨论。

首先是 人工备份 ,这是最low的方案,当然也是最简单的,即有人定期去备份就行了。问题是时效性不高,例如一天备份一次,如果磁盘在备份前坏了,那就会丢失一天的数据。同时恢复比较耗时,需要人工处理。

第二个方案是 代码实现 ,即在上传文件时,程序就自动备份。以上面的架构为例,可以添加一个BackupListener,当上传完成后,通过事件,自动备份上传的文件。同时下载时需要判定文件是否完整,如果有问题则使用备份数据。此方案时效性得到了保障,但是将数据备份和业务放到了一起,且需要编码实现,增加了业务代码量。

第三个方案是 libfuse ,libfuse是用户态文件系统接口。下面是libfuse官方简介:

简单来说,就是可以用libfuse构建一个用户态文件系统。之前在老东家做了一个日志分析平台,日志的收集就使用了libfuse,大致架构如下:

业务系统写日志到挂载的用户态文件系统中,用户态文件系统自动转发到了后续的处理中间件:redis、消息队列、文件系统。

在这里也可以用类似的功能,即在文件上传后,用户态文件系统自动备份。此方案解耦了文件备案逻辑与业务逻辑。

最后一个方案是 RAID ,即廉价冗余磁盘阵列。RAID不但可备份文件,还支持并发读写,提高上传下载速率。

常用的RAID有:RAID0,RAID1,RAID01/RAID10,RAID5和RAID6等。我们来看看这几种RAID的特点,以及是否适用于我们的文件服务。文件系统接口设计图你会发现从RAID0到RAID6,又是一个从单点到分布式的过程。

看下面的两张图应该能更好的理解:

无论是RAID10还是RAID01,对磁盘的使用效率都不高。那如何提高磁盘使用率呢?就有了RAID3。

对于本地存储来说,RAID是个相对实用的解决方案,既能提高数据安全、快速扩容,也提高了读写速率。但是无论扩展多少磁盘,容量还是相对有限,吞吐也相对有限,同时由于其还是单点,如果文件服务本身挂掉,就会导致单点故障。所以就有了分布式文件系统。

分布式文件系统下次单独讨论!

最后打个广告,帮朋友开的专栏《零基础Unity3D 游戏 开发》,适合没有基础、想从事 游戏 开发的小白!朋友从事 游戏 多年,开发了多款 游戏 ,收了30多个徒弟,技术杠杠的!

程序员必备知识(操作系统5-文件系统)

本篇与之前的第三篇的内存管理知识点有相似的地方

对于运行的进程来说,内存就像一个纸箱子, 仅仅是一个暂存数据的地方, 而且空间有限。如果我们想要进程结束之后,数据依然能够保存下来,就不能只保存在内存里,而是应该保存在 外部存储 中。就像图书馆这种地方,不仅空间大,而且能够永久保存。

我们最常用的外部存储就是 硬盘 ,数据是以文件的形式保存在硬盘上的。为了管理这些文件,我们在规划文件系统的时候,需要考虑到以下几点。

第一点,文件系统要有严格的组织形式,使得文件能够 以块为单位进行存储 。这就像图书馆里,我们会给设置一排排书架,然后再把书架分成一个个小格子,有的项目存放的资料非常多,一个格子放不下,就需要多个格子来进行存放。我们把这个区域称为存放原始资料的 仓库区 。

第二点,文件系统中也要有 索引区 ,用来方便查找一个文件分成的多个块都存放在了什么位置。这就好比,图书馆的书太多了,为了方便查找,我们需要专门设置一排书架,这里面会写清楚整个档案库有哪些资料,资料在哪个架子的哪个格子上。这样找资料的时候就不用跑遍整个档案库,在这个书架上找到后,直奔目标书架就可以了。

第三点,如果文件系统中有的文件是热点文件,近期经常被读取和写入,文件系统应该有 缓存层 。这就相当于图书馆里面的热门图书区,这里面的书都是畅销书或者是常常被借还的图书。因为借还的次数比较多,那就没必要每次有人还了之后,还放回遥远的货架,我们可以专门开辟一个区域, 放置这些借还频次高的图书。这样借还的效率就会提高。

第四点,文件应该用 文件夹 的形式组织起来,方便管理和查询。这就像在图书馆里面,你可以给这些资料分门别类,比如分成计算机类.文学类.历史类等等。这样你也容易管理,项目组借阅的时候只要在某个类别中去找就可以了。

在文件系统中,每个文件都有一个名字,这样我们访问一个文件,希望通过它的名字就可以找到。文件名就是一个普通的文本。 当然文件名会经常冲突,不同用户取相同的名字的情况还是会经常出现的。

要想把很多的文件有序地组织起来,我们就需要把它们成为 目录 或者文件夹。这样,一个文件夹里可以包含文件夹,也可以包含文件,这样就形成了一种 树形结构 。而我们可以将不同的用户放在不同的用户目录下,就可以一定程度上避免了命名的冲突问题。

第五点,Linux 内核要在自己的内存里面维护一套数据结构,来保存哪些文件被哪些进程打开和使用 。这就好比,图书馆里会有个图书管理系统,记录哪些书被借阅了,被谁借阅了,借阅了多久,什么时候归还。
文件系统是操作系统中负责管理持久数据的子系统,说简单点,就是负责把用户的文件存到磁盘硬件中,因为即使计算机断电了,磁盘里的数据并不会丢失,所以可以持久化的保存文件。

文件系统的基本数据单位是 文件 ,它的目的是对磁盘上的文件进行组织管理,那组织的方式不同,就会形成不同的文件系统。

Linux最经典的一句话是:“一切皆文件”,不仅普通的文件和目录,就连块设备、管道、socket 等,也都是统一交给文件系统管理的。

Linux文件系统会为每个文件分配两个数据结构: 索引节点(index node) 和 目录项(directory entry) ,它们主要用来记录文件的元信息和目录层次结构。

●索引节点,也就是inode, 用来记录文件的元信息,比如inode编号、文件大小访问权限、创建时间、修改时间、 数据在磁盘的位置 等等。 索引节点是文件的唯一标识 ,它们之间一一对应, 也同样都会被 存储在硬盘 中,所以索引节点同样占用磁盘空间。

●目录项,也就是dentry, 用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来,就会形成 目录结构 ,但它与索引节点不同的是,目录项是由内核维护的一个数据结构,不存放于磁盘,而是 缓存在内存 。

由于索引节点唯一标识一个文件,而目录项记录着文件的名,所以目录项和索引节点的关系是多对一,也就是说,一个文件可以有多个别字。比如,硬链接的实现就是多个目录项中的索引节点指向同一个文件。

注意,目录也是文件,也是用索引节点唯一标识,和普通文件不同的是,普通文件在磁盘里面保存的是文件数据,而目录文件在磁盘里面保存子目录或文件。

(PS:目录项和目录不是一个东西!你也不是一个东西(^_=), 虽然名字很相近,但目录是个文件。持久化存储在磁盘,而目录项是内核一个数据结构,缓存在内存。

如果查询目录频繁从磁盘读,效率会很低,所以内核会把已经读过的目录用目录项这个数据结构缓存在内存,下次再次读到相同的目录时,只需从内存读就可以,大大提高了 文件系统的效率。

目录项这个数据结构不只是表示目录,也是可以表示文件的。)

磁盘读写的最小单位是 扇区 ,扇区的大小只有512B大小,很明显,如果每次读写都以这么小为单位,那这读写的效率会非常低。

所以,文件系统把多个扇区组成了一个 逻辑块 ,每次读写的最小单位就是逻辑块(数据块) , Linux中的逻辑块大小为4KB,也就是一次性读写 8个扇区,这将大大提高了磁盘的读写的效率。

以上就是索引节点、目录项以及文件数据的关系,下面这个图就很好的展示了它们之间的关系:

索引节点是存储在硬盘上的数据,那么为了加速文件的访问,通常会把索引节点加载到内存中。

另外,磁盘进行格式化的时候,会被分成三个存储区域,分别是超级块、索引节点区和数据块区。

●超级块,用来存储文件系统的详细信息,比如块个数、块大小、空闲块等等。

●索引节点区,用来存储索引节点;

●数据块区,用来存储文件或目录数据;

我们不可能把超级块和索引节点区全部加载到内存,这样内存肯定撑不住,所以只有当需要使用的时候,才将其加载进内存,它们加载进内存的时机是不同的.

●超级块:当文件系统挂载时进入内存;

●索引节点区:当文件被访问时进入内存;
文件系统的种类众多,而操作系统希望 对用户提供一个统一的接口 ,于是在用户层与文件系统层引入了中间层,这个中间层就称为 虚拟文件系统(Virtual File System, VFS) 。

VFS定义了一组所有文件系统都支持的数据结构和标准接口,这样程序员不需要了解文件系统的工作原理,只需要了解VFS提供的统一接口即可。

在Linux文件系统中,用户空间、系统调用、虚拟机文件系统、缓存、文件系统以及存储之间的关系如下图:

Linux支持的文件系统也不少,根据存储位置的不同,可以把文件系统分为三类:

●磁盘的文件系统,它是直接把数据存储在磁盘中,比如Ext 2/3/4. XFS 等都是这类文件系统。

●内存的文件系统,这类文件系统的数据不是存储在硬盘的,而是占用内存空间,我们经常用到的/proc 和/sys文件系统都属于这一类,读写这类文件,实际上是读写内核中相关的数据。

●网络的文件系统,用来访问其他计算机主机数据的文件系统,比如NFS. SMB等等。

文件系统首先要先挂载到某个目录才可以正常使用,比如Linux系统在启动时,会把文件系统挂载到根目录。
在操作系统的辅助之下,磁盘中的数据在计算机中都会呈现为易读的形式,并且我们不需要关心数据到底是如何存放在磁盘中,存放在磁盘的哪个地方等等问题,这些全部都是由操作系统完成的。

那么,文件数据在磁盘中究竟是怎么样的呢?我们来一探究竟!

磁盘中的存储单元会被划分为一个个的“ 块 ”,也被称为 扇区 ,扇区的大小一般都为512byte.这说明即使一块数据不足512byte,那么它也要占用512byte的磁盘空间。

而几乎所有的文件系统都会把文件分割成固定大小的块来存储,通常一个块的大小为4K。如果磁盘中的扇区为512byte,而文件系统的块大小为4K,那么文件系统的存储单元就为8个扇区。这也是前面提到的一个问题,文件大小和占用空间之间有什么区别?文件大小是文件实际的大小,而占用空间则是因为即使它的实际大小没有达到那么大,但是这部分空间实际也被占用,其他文件数据无法使用这部分的空间。所以我们 写入1byte的数据到文本中,但是它占用的空间也会是4K。

这里要注意在Windows下的NTFS文件系统中,如果一开始文件数据小于 1K,那么则不会分配磁盘块来存储,而是存在一个文件表中。但是一旦文件数据大于1K,那么不管以后文件的大小,都会分配以4K为单位的磁盘空间来存储。

与内存管理一样,为了方便对磁盘的管理,文件的逻辑地址也被分为一个个的文件块。于是文件的逻辑地址就是(逻辑块号,块内地址)。用户通过逻辑地址来操作文件,操作系统负责完成逻辑地址与物理地址的映射。

不同的文件系统为文件分配磁盘空间会有不同的方式,这些方式各自都有优缺点。

连续分配要求每个文件在磁盘上有一组连续的块,该分配方式较为简单。

通过上图可以看到,文件的逻辑块号的顺序是与物理块号相同的,这样就可以实现随机存取了,只要知道了第一个逻辑块的物理地址, 那么就可以快速访问到其他逻辑块的物理地址。那么操作系统如何完成逻辑块与物理块之间的映射呢?实际上,文件都是存放在目录下的,而目录是一种有结构文件, 所以在文件目录的记录中会存放目录下所有文件的信息,每一个文件或者目录都是一个记录。 而这些信息就包括文件的起始块号和占有块号的数量。

那么操作系统如何完成逻辑块与物理块之间的映射呢? (逻辑块号, 块内地址) - (物理块号, 块内地址),只需要知道逻辑块号对应的物理块号即可,块内地址不变。

用户访问一个文件的内容,操作系统通过文件的标识符找到目录项FCB, 物理块号=起始块号+逻辑块号。 当然,还需要检查逻辑块号是否合法,是否超过长度等。因为可以根据逻辑块号直接算出物理块号,所以连续分配支持 顺序访问和随机访问 。

因为读/写文件是需要移动磁头的,如果访问两个相隔很远的磁盘块,移动磁头的时间就会变长。使用连续分配来作为文件的分配方式,会使文件的磁盘块相邻,所以文件的读/写速度最快。

连续空间存放的方式虽然读写效率高,但是有 磁盘空间碎片 和 文件长度不易扩展 的缺陷。

如下图,如果文件B被删除,磁盘上就留下一块空缺,这时,如果新来的文件小于其中的一个空缺,我们就可以将其放在相应空缺里。但如果该文件的大小大于所

有的空缺,但却小于空缺大小之和,则虽然磁盘上有足够的空缺,但该文件还是不能存放。当然了,我们可以通过将现有文件进行挪动来腾出空间以容纳新的文件,但是这个在磁盘挪动文件是非常耗时,所以这种方式不太现实。

另外一个缺陷是文件长度扩展不方便,例如上图中的文件A要想扩大一下,需要更多的磁盘空间,唯一的办法就只能是挪动的方式,前面也说了,这种方式效率是非常低的。

那么有没有更好的方式来解决上面的问题呢?答案当然有,既然连续空间存放的方式不太行,那么我们就改变存放的方式,使用非连续空间存放方式来解决这些缺陷。
非连续空间存放方式分为 链表方式 和 索引方式 。

链式分配采取离散分配的方式,可以为文件分配离散的磁盘块。它有两种分配方式:显示链接和隐式链接。

隐式链接是只目录项中只会记录文件所占磁盘块中的第一块的地址和最后一块磁盘块的地址, 然后通过在每一个磁盘块中存放一个指向下一 磁盘块的指针, 从而可以根据指针找到下一块磁盘块。如果需要分配新的磁盘块,则使用最后一块磁盘块中的指针指向新的磁盘块,然后修改新的磁盘块为最后的磁盘块。

我们来思考一个问题, 采用隐式链接如何将实现逻辑块号转换为物理块号呢?

用户给出需要访问的逻辑块号i,操作系统需要找到所需访问文件的目录项FCB.从目录项中可以知道文件的起始块号,然后将逻辑块号0的数据读入内存,由此知道1号逻辑块的物理块号,然后再读入1号逻辑块的数据进内存,此次类推,最终可以找到用户所需访问的逻辑块号i。访问逻辑块号i,总共需要i+ 1次磁盘1/0操作。

得出结论: 隐式链接分配只能顺序访问,不支持随机访问,查找效率低 。

我们来思考另外一个问题,采用隐式链接是否方便文件拓展?

我们知道目录项中存有结束块号的物理地址,所以我们如果要拓展文件,只需要将新分配的磁盘块挂载到结束块号的后面即可,修改结束块号的指针指向新分配的磁盘块,然后修改目录项。

得出结论: 隐式链接分配很方便文件拓展。所有空闲磁盘块都可以被利用到,无碎片问题,存储利用率高。

显示链接是把用于链接各个物理块的指针显式地存放在一张表中,该表称为文件分配表(FAT, File Allocation Table)。

由于查找记录的过程是在内存中进行的,因而不仅显著地 提高了检索速度 ,而且 大大减少了访问磁盘的次数 。但也正是整个表都存放在内存中的关系,它的主要的缺点是 不适 用于大磁盘 。

比如,对于200GB的磁盘和1KB大小的块,这张表需要有2亿项,每一项对应于这2亿个磁盘块中的一个块,每项如果需要4个字节,那这张表要占用800MB内存,很显然FAT方案对于大磁盘而言不太合适。

一直都在,加油!(*゜Д゜)σ凸←自爆按钮

链表的方式解决了连续分配的磁盘碎片和文件动态打展的问题,但是不能有效支持直接访问(FAT除外) ,索引的方式可以解决这个问题。

索引的实现是为每个文件创建一个 索引数据块 ,里面存放的 是指向文件数据块的指针列表 ,说白了就像书的目录一样,要找哪个章节的内容,看目录查就可以。

另外, 文件头需要包含指向索引数据块的指针 ,这样就可以通过文件头知道索引数据块的位置,再通过索弓|数据块里的索引信息找到对应的数据块。

创建文件时,索引块的所有指针都设为空。当首次写入第i块时,先从空闲空间中取得一个块, 再将其地址写到索引块的第i个条目。

索引的方式优点在于:

●文件的创建、增大、缩小很方便;

●不会有碎片的问题;

●支持顺序读写和随机读写;

由于索引数据也是存放在磁盘块的,如果文件很小,明明只需一块就可以存放的下,但还是需要额外分配一块来存放索引数据,所以缺陷之一就是存储索引带来的开销。

如果文件很大,大到一个索引数据块放不下索引信息,这时又要如何处理大文件的存放呢?我们可以通过组合的方式,来处理大文件的存储。

先来看看 链表+索引 的组合,这种组合称为 链式索引块 ,它的实现方式是在 索引数据块留出一个存放下一个索引数据块的指针 ,于是当一个索引数据块的索引信息用完了,就可以通过指针的方式,找到下一个索引数据块的信息。那这种方式也会出现前面提到的链表方式的问题,万一某个指针损坏了,后面的数据也就会无法读取了。

还有另外一种组合方式是 索引+索引 的方式,这种组合称为多级索引块,实现方式是通过一个索引块来存放多个索引数据块,一层套一层索引, 像极了俄罗斯套娃是吧๑乛◡乛๑ 

前面说到的文件的存储是针对已经被占用的数据块组织和管理,接下来的问题是,如果我要保存一个数据块, 我应该放在硬盘上的哪个位置呢?难道需要将所有的块扫描一遍,找个空的地方随便放吗?

那这种方式效率就太低了,所以针对磁盘的空闲空间也是要引入管理的机制,接下来介绍几种常见的方法:

●空闲表法

●空闲链表法

●位图法

空闲表法

空闲表法就是为所有空闲空间建立一张表,表内容包括空闲区的第一个块号和该空闲区的块个数,注意,这个方式是连续分配的。如下图:

当请求分配磁盘空间时,系统依次扫描空闲表里的内容,直到找到一个合适的空闲区域为止。当用户撤销一个文件时,系统回收文件空间。这时,也需顺序扫描空闲表,寻找一个空闲表条目并将释放空间的第一个物理块号及它占用的块数填到这个条目中。

这种方法仅当有少量的空闲区时才有较好的效果。因为,如果存储空间中有着大量的小的空闲区,则空闲表变得很大,这样查询效率会很低。另外,这种分配技术适用于建立连续文件。

空闲链表法

我们也可以使用链表的方式来管理空闲空间,每一个空闲块里有一个指针指向下一个空闲块,这样也能很方便的找到空闲块并管理起来。如下图:

当创建文件需要一块或几块时,就从链头上依次取下一块或几块。反之,当回收空间时,把这些空闲块依次接到链头上。

这种技术只要在主存中保存一个指针, 令它指向第一个空闲块。其特点是简单,但不能随机访问,工作效率低,因为每当在链上增加或移动空闲块时需要做很多1/0操作,同时数据块的指针消耗了一定的存储空间。

空闲表法和空闲链表法都不适合用于大型文件系统,因为这会使空闲表或空闲链表太大。

位图法

位图是利用二进制的一位来表示磁盘中一个盘块的使用情况,磁盘上所有的盘块都有一个二进制位与之对应。

当值为0时,表示对应的盘块空闲,值为1时,表示对应的盘块已分配。它形式如下:

在Linux文件系统就采用了位图的方式来管理空闲空间,不仅用于数据空闲块的管理,还用于inode空闲块的管理,因为inode也是存储在磁盘的,自然也要有对其管理。
前面提到Linux是用位图的方式管理空闲空间,用户在创建一个新文件时, Linux 内核会通过inode的位图找到空闲可用的inode,并进行分配。要存储数据时,会通过块的位图找到空闲的块,并分配,但仔细计算一下还是有问题的。

数据块的位图是放在磁盘块里的,假设是放在一个块里,一个块4K,每位表示一个数据块,共可以表示4 * 1024 * 8 = 2^15个空闲块,由于1个数据块是4K大小,那么最大可以表示的空间为2^15 * 4 * 1024 = 2^27个byte,也就是128M。

也就是说按照上面的结构,如果采用(一个块的位图+ 一系列的块),外加一(个块的inode的位图+一系列的inode)的结构能表示的最大空间也就128M,

这太少了,现在很多文件都比这个大。

在Linux文件系统,把这个结构称为一个 块组 ,那么有N多的块组,就能够表示N大的文件。

最终,整个文件系统格式就是下面这个样子。

最前面的第一个块是引导块,在系统启动时用于启用引导,接着后面就是一个一个连续的块组了,块组的内容如下:

● 超级块 ,包含的是文件系统的重要信息,比如inode总个数、块总个数、每个块组的inode个数、每个块组的块个数等等。

● 块组描述符 ,包含文件系统中各个块组的状态,比如块组中空闲块和inode的数目等,每个块组都包含了文件系统中「所有块组的组描述符信息」。

● 数据位图和inode位图 ,用于表示对应的数据块或inode是空闲的,还是被使用中。

● inode 列表 ,包含了块组中所有的inode, inode 用于保存文件系统中与各个文件和目录相关的所有元数据。

● 数据块 ,包含文件的有用数据。

你可以会发现每个块组里有很多重复的信息,比如 超级块和块组描述符表,这两个都是全局信息,而且非常的重要 ,这么做是有两个原因:

●如果系统崩溃破坏了超级块或块组描述符,有关文件系统结构和内容的所有信息都会丢失。如果有冗余的副本,该信息是可能恢复的。

●通过使文件和管理数据尽可能接近,减少了磁头寻道和旋转,这可以提高文件系统的性能。

不过,Ext2 的后续版本采用了稀疏技术。该做法是,超级块和块组描述符表不再存储到文件系统的每个块组中,而是只写入到块组0、块组1和其他ID可以表示为3、5、7的幂的块组中。
在前面,我们知道了一个普通文件是如何存储的,但还有一个特殊的文件,经常用到的目录,它是如何保存的呢?

基于Linux 一切切皆文件的设计思想,目录其实也是个文件,你甚至可以通过vim打开它,它也有inode, inode 里面也是指向一些块。

和普通文件不同的是, 普通文件的块里面保存的是文件数据,而目录文件的块里面保存的是目录里面一项一项的文件信息 。

在目录文件的块中,最简单的保存格式就是 列表 ,就是一项一项地将目录下的文件信息(如文件名、文件inode.文件类型等)列在表里。

列表中每一项就代表该目录下的文件的文件名和对应的inode,通过这个inode,就可以找到真正的文件。

通常,第一项是「则」,表示当前目录,第二项是.,表示上一级目录, 接下来就是一项一项的文件名和inode。

如果一个目录有超级多的文件,我们要想在这个目录下找文件,按照列表一项一项的找,效率就不高了。

于是,保存目录的格式改成 哈希表 ,对文件名进行哈希计算,把哈希值保存起来,如果我们要查找一个目录下面的文件名,可以通过名称取哈希。如果哈希能够匹配上,就说明这个文件的信息在相应的块里面。

Linux系统的ext文件系统就是采用了哈希表,来保存目录的内容,这种方法的优点是查找非常迅速,插入和删除也较简单,不过需要一些预备措施来避免哈希冲突。

目录查询是通过在磁盘上反复搜索完成,需要不断地进行/0操作,开销较大。所以,为了减少/0操作,把当前使用的文件目录缓存在内存,以后要使用该文件时只要在内存中操作,从而降低了磁盘操作次数,提高了文件系统的访问速度。

感谢您的阅读,希望您能摄取到知识!加油!冲冲冲!(发现光,追随光,成为光,散发光!)我是程序员耶耶!有缘再见。<-biubiu-⊂(`ω´∩)

基于flash存储器的文件系统有哪些

Flash 存储器( Flash Memory) 是一种高可靠性、高密度的固态存储器件。 其存储方式是完全非易失性的,掉电后可以保存数据;可以在线写入,并可按页连续字节写入,存取速度快,所以嵌入式系统通常使用Flash 存储器作为存储设备。 但Flash存储器也存在着两个主要缺陷:一是在重写之前必须进行擦除,因为Flash 存储器划分成很多擦除块(SectorOErase) ,对任何一位数据进行修改必须先擦除整个块(Sector) ;二是擦除块的擦除次数有限,当一个块提前达到擦除次数上限时, 将导致整个Flash 存储器无法使用。 所以,目前PC 机上很多成熟的基于磁盘的文件系统在Flash 存储器上使用都存在着不足。
嵌入式系统应具有的特点: 一是高可靠性,在恶劣环境下系统仍能正常工作;二是低消耗,受成本限制系统设计必须量体裁衣,去除冗余;三是高效率,在占用较少资源情况下保证功能需求,这样就要求算法简单,效率高。 而日志文件系统(Log-St ruct ured File System) 在数据更新时无需将数据写入原存储区域,适应Flash 存储器无法进行重写这一特点。 目前,针对Flash 存储器的缺陷而设计的Linux 下的J FFS 文件系统,就是采用简化的日志文件系统。 J FFS 文件系统将磨损均衡集成于清除机制之中,在带来掉电可恢复功能的同时,大大减少了块擦除的次数,提高了文件系统的存取速度和效率。 但是,J FFS 文件系统无法单独使用,或者使用于其它实时操作系统中。 对由于受成本和实时性限制而无法使用Linux 的一些嵌入式系统,也就无法使用J FFS 文件系统。基于上述分析,该嵌入式文件系统适合在开源实时操作系统(如μC/OS-II) 和无操作系统的情况下使用。
嵌入式文件系统原理
在日志文件系统中,一个文件被修改后不是被写入到原来的存储空间,而是被加到所有内容的后面,象日志一样被更新,这就是日志文件系统的基本原理。 由于同一个文件在文件系统中会留下不同的版本,所以系统需要设置一张表标注文件的最新与以前的版本。 在内容不断添加时为不将存储空间占满,系统设计了一种回收机制,回收无效内容占用的空间。
日志文件系统在文件更新时不用将文件写回原来的地址,这对Flash 存储器这种存储介质最为适合。 文中所设计的嵌入式文件系统采用了日志文件系统的设计原理,以及J FFS 文件系统将磨损均衡集成于清除机制之中的方法。 该系统将一个可擦写块平分为多个簇,文件的读写以簇为单位进行。簇的状态有3 种:脏、干净和空。 脏表示所存内容已被置为无效;干净表示所存数据有效;空表示可以写入数据。 文件和目录在该系统中被作为节点,一个节点占用若干个簇,节点中的内容连续存储,但不能越过块边界存储。 该系统设置一个索引节点,保存整个系统的信息,其中包含保存有各簇状态的簇状态表。
每一次文件更新后内容都将被添加至末尾处,索引节点也被更新,总是占用最末尾的干净簇。 回收脏簇时,将所要擦除块中的干净簇重写到空簇中,再进行块擦除。 当内容写至存储体末端,则从头部重新开始循环存储。 所设计的文件系统的操作过程见图1。
ic72新闻中心
嵌入式文件系统设计
Flash 存储器中的存储结构
Flash 存储器中的存储结构见图2。 该存储器中每个簇的第一个字作为簇的状态字,表示此簇是否为一个节点的首簇或空簇。 每个节点的首部存放此节点属性(文件/目录/索引节点) 和节点标识号。
ic72新闻中心
索引节点
索引节点存放该文件系统的大部分信息。 包括32 位的索引节点更新号、一张簇状态表、下一个要被擦除块的块号、给下一个新建节点(文件或目录) 的节点编号、系统根目录信息表。系统每一次更新都会产生新的索引节点,索引节点更新号加1。 按照Flash 存储器的使用寿命10 年计算,需要每秒更新136 次以上,才能达到索引节点更新号的上限,所以认为拥有最大更新号的索引节点为最新的索引节点。 簇状态表中对应每一个簇有两个Bit 位,表示各个簇的状态(干净01 ,脏11 ,空00) 。 根目录信息表存放根目录下的各个目录项,每个目录项包括:属性(文件0x1/目录0x0) 、文件名或目录名、节点编号、此文件(或目录) 对应节点的起始簇地址、根目录表的大小可变。
目录节点
目录节点存放的内容有目录名,目录项个数,及所有目录项信息。 文件节点存放文件名,文件大小,文件属性及文件内容,内存中的目录结构见图3。
ic72新闻中心
内存数据结构及基本操作
该文件系统载入(Mount ) 后,会在内存中建立一个系统的映象。 该映象包括:索引节点中的信息、目录及文件信息、每个可擦写块中包含的节点信息、未存盘的节点信息。 簇状态表、索引节点更新号、新节点编号、下一擦除块号等索引节点中的内容,在内存中均作为不同的变量。 内存中为每个文件和目录都建立了映象,数据结构见图4 和图5。
ic72新闻中心
ic72新闻中心
内存中的文件节点不包含文件真正的数据,而使用指针。 文件被打开时,在内存中创建一块新存储区域存放数据,数据指针便指向此存储区,未被打开时,此指针指向空。 对于每个目录有1 个目录层数,表示此目录的深度,如根目录的目录层数为0 ,根目录的下一级目录则为1 ,依此类推。 存储地址保存文件或目录在Flash 中的地址。 文件和目录都被存在上一级目录下,所属目录指针即指向上一级目录在内存中的数据结构,根目录的所属目录指针即为空。 对于同目录下的不同节点,在内存中使用链表将其串联,同目录文件指针即联成链表。 链表的首指针保存在上一级目录中,首目录项指针即指向链表的首项。 为提高块擦写的效率,存储在同一个可擦写块中的各个节点在内存中也建立一个链表,块队列指针即用于连成此链表。 为标识被修改的节点,利用一个未保存队列,未保存队列指针即用来建立此队列。
该文件系统载入(mount ) 时,首先顺序扫描Flash 中的每个索引节点,查找出最大的索引节点更新号,此更新号对应的索引节点即为最新的索引节点。 查找到最新索引节点后,将簇状态表等信息映射到内存的数据结构中。 依据索引节点中的根目录信息,遍历所有节点,建立内存中的目录文件结构,并将节点添加到对应的擦写块队列中。 对一个文件编辑并保存的过程见图6。
ic72新闻中心
文件打开时,先在内存中分配一块空间作为数据区,将内容写入,并定位文件节点的数据指针指向该内存中的数据区。 如果文件内容被修改,就将文件节点添加到未存盘队列,依次写入Flash 存储器中,并修改簇状态表。 保存时将内存中数据区内容写入Fhttp://www.xiupin365.net/sitemap.html?lash 中,释放申请的内存空间,修改节点中的数据指针和簇状态表,再将文件的所有上级目录重新写入Flash ,最后将更新后的索引节点内容写入Flash。 如果文件未被修改,则只需修改数据指针即可。
节点加入未存盘队列的顺序按照目录层数的大小排列,文件节点排在队列首,目录层数最大的排在其后,目录层数为1 的排在队列末尾,根目录不加入未存盘队列。
嵌入式文件系统特殊处理机制
均衡擦写机制
为了避免任意一个可擦除块因擦写次数过多而过早报废,文件系统对Flash擦写时采用了均衡擦写机制。 考虑到系统的精简性,擦写在整片Flash 的各块中依次进行,一块擦写完后,下一个被擦写的块即为后一个块,在系统的索引节点中保存了下一个要擦除的块号。 当文件系统中的剩余空间减少到设定值时,系统会擦除此块,以回收脏簇占用的空间。 对应每个可擦写块都有一个节点队列,此块中包含的节点都加入其中。块擦除的流程见图7。
ic72新闻中心
首先,将未保存于队列中的节点保存,清未保存队列。 然后将块队列中的所有文件节点转移到空簇中,同时将文件路径上的各级目录加入到未存盘队列中。 对于块队列中的目录节点,则将它和其路径上的各级目录加入未存盘队列中,按照未保存队列的顺序,依次将各个目录写入Flash 中,最后写入最新的索引节点。 因为目录节点加入未存盘队列时,按照目录层数的大小排列,所以按照未保存队列的顺序写入时,可以保证当一个目录要被写入Flash 时,它的所有下级目录已被写入Flash 中。 所有下级目录在Flash 中的存储地址都已确定。当该文件系统的空间将达到存储上限时,可能会出现特殊情况,即废簇回收时,空簇的空间不足,无法将所有干净簇重写。 文件系统为此建立了应急机制,先将文件节点内容存在内存中,这时新建一个临时未保存队列,专门保存文件节点,在块擦写完成后,将剩余的文件节点写入新的空簇中,其算法与图7 所示流程大致相同。 但是,一旦在擦写时断电,会导致该块上的所有数据丢失。
断电错误处理机制
当系统遭遇断电重新启动后,索引节点中的信息会与系统中的状态不符,这时便需要错误处理机制。 错误一般是索引节点中标注的空簇已被写入了数据,错误处理就是将此簇标志为脏簇,并查找下一个空簇重新写入。
多任务处理机制
该文件系统允许同时打开多个文件,在多任务操作系统下,为了避免冲突建立了多任务处理机制。 系统允许打开的多个文件在内存中同时被编辑修改,但是对Flash 写入操作有限制。 处理方法是设立Flash 写入保护区,在此区中只允许当前正在执行的任务执行Flash 写入操作。 实现Flash 写入保护区的方法是建立一个初始值为1 的信号量,当一个节点需要Flash 写入时,首先申请信号量,完成后再释放信号量。 Flash 写入保护区见图6 、图7。在图6 中,空操作语句是用来对多个文件的保存进行同步。 例如,有文件1 和文件2 需要保存,先将文件1 的内容写入Flash 中,文件1 路径下的目录节点被添加到未保存队列中,再将文件2 的内容写入Flash 中,文件2 路径下的目录节点也被添加到未保存队列中,最后将未保存队列中的所有节点都写入Flash 中。 这样,如果同一路径下的两个文件同时存盘,可避免路径下的相同目录节点被写入两次,从而提高了效率。 不足之处在于,如果很多文件同时存盘,会导致索引节点在一段时间内都无法写入Flash 存储器,有断电丢失的危险。 但对于一般嵌入式系统来说,很少会碰到这种情况。 当进行Flash存储器擦写时,在取块队列首节点至索引节点写入完成这段时间内都不允许进行其他Flash 存储器的写入操作,这是为了保证数据的完整性,同时也提高了文件系统的稳定性。
无目录文件系统的优化
许多嵌入式系统设计中虽没有目录管理的要求,但是对执行效率和资源消耗的要求较高。 对于不要求有目录管理的精简文件系统,在设计时也进行了优化。 精简文件系统在Flash 中的存储格式与上述设计相同,文件系统中的所有文件信息都保存在索引节点的根目录信息表中。 精简文件系统在内存中的映象则要简单很多,只包含索引节点中的信息,包括簇状态表、下一个擦除块、下一个新节点的标号和根目录信息,而不用为每个文件都建立内存中的映象,节省大量的内存空间。 文件的编辑存盘过程简化为:打开文件、编辑、将文件写入Flash 存储器、将修改后的索引节点写入Flash 存储器。 擦写则只需通过查询根目录信息表中的各个目录项,将块中的所有文件节点写入空簇即可。在无目录管理的情况下,精简文件系统占用的内存资源可以减少,操作也可便捷,提高了效率。 对于大量只需要按名存取的简单文件管理的小型嵌入式系统而言,针对Flash 存储器的简单文件系统将占用资源少,执行效率高,有很大的应用价值。
嵌入式文件系统实现及性能分析
该文件系统的实现采用了分层方法,分为3 层4 个部分:应用程序接口、文件系统核心、操作系统调用接口、Flash 存储器驱动,实现结构见图8。
ic72新闻中心
实现平台中RTOS 为μC/OSOII 实时操作系统,CPU 使用三星S4510B作为处理器,Flash 存储器芯片为FUJ ITSU 的29LV160 TE。 针对不同的实时操作系统和Flash 存储器芯片需要实现不同的操作系统接口和Flash 存储器驱动。
针对μC/ OSOII 编写操作系统调用接口,包括5个函数: ①系统调用接口初始化FS_Sys_Interface_Init ( ) ,创建互斥信号量和内存分区; ② Flash 写入关闭FS_Sys_Write_Lock ( ) ,禁止Flash 写入操作,调用μC/OS-II 中OSMutePend ( ) ; ③ Flash写入打开FS_Sys_Write_Unlock ( ) ,重新允许Flash 写入操作,调用μC/OS-II 中OSMutePost() ; ④内存空间申请FS_Sys_Mem_Alloc( ) 和内存空间添加FS_Sys_Mem_Add ( ) , 都调用OSMemGet ( ) 来完成; ⑤内存空间释放FS_Sys_Mem_Free ( ) ,调用OSMemPut ( ) 完成,将申请的内存块全部释放。针对29LV160 TE 这款Flash 存储器芯片,定义一个FlashDef 结构体的全局变量, 用于存储Flash 器件信息,并且编写针对此款Flash 的块擦写函数FS_Device_Sector_Erase ( ) 和数据写入函数FJ FS_Device_Write ( ) 。
完成这两部分的实现后,该系统就可运行调试。 测试应用程序接口(API) 。 应该提供的各部分功能,并在突然断电情况下,测试文件系统的恢复情况。无目录管理的精简文件系统的载入,可在2μs内完成,文件写入耗时主要为闪存的等待时间,系统本身只占用不到200 个字节的内存,产生的代码段大小为7 K。 完整的文件系统载入时,需要建立内存中映象,耗时根据文件数量的多少而不同,一般为10μs ,产生的代码段大小为11 K。 系统写入效率较高,在无目录管理的配置下尤其明显。 试验中系统在多次断电的情况下,系统仍能恢复至上次存盘的状态,虽会导致个别文件未更新,但不会导致文件系统崩溃。

linux 文件系统 是什么意思

文件系统是操作系统用于明确存储设备(常见的是磁盘,也有基于NANDFlash的固态硬盘)或分区上的文件的方法和数据结构;
即在存储设备上组织文件的方法。
操作系统中负责管理和存储文件信息的软件机构称为文件管理系统,简称文件系统。
文件系统由三部分组成:文件系统的接口,对对象操纵和管理的软件集合,对象及属性。
从系统角度来看,文件系统是对文件存储设备的空间进行组织和分配,负责文件存储并对存入的文件进行保护和检索的系统。 关于文件系统接口设计图和接口文件和实现文件的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。 文件系统接口设计图的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于接口文件和实现文件、文件系统接口设计图的信息别忘了在本站进行查找喔。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Java 8 Lambda 表达式比较器使用示例代码
下一篇:kaptcha验证码组件使用简介解析
相关文章

 发表评论

暂时没有评论,来抢沙发吧~