Linux下常见文件系统的示例分析

76次阅读
没有评论

共计 3912 个字符,预计需要花费 10 分钟才能阅读完成。

这篇文章主要介绍了 Linux 下常见文件系统的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让丸趣 TV 小编带着大家一起了解一下。

历史

文件系统创建者创建时间最开始支持的平台 ext2R eacute;my Card1993Linux,HurdXFSSGI1994IRIX, Linux, FreeBSDext3Dr. Stephen C. Tweedie1999LinuxZFSSun2004Solarisext4 众多开发者 2006LinuxBtrfsOracle2007Linux

从创建时间可以看出他们所处的不同时代,因为 Btrfs 的实现借鉴自 ZFS,所以这里也将 ZFS 列出来作为参考。

大小限制

文件系统 *** 文件名长度 *** 文件大小 *** 分区大小 ext2255 bytes2 TB16 TBext3255 bytes2 TB16 TBext4255 bytes16 TB1 EBXFS255 bytes8 EB8 EBBtrfs255 bytes16 EB16 EB

*** 文件和分区大小受格式化分区时所采用的块大小 (block size) 所影响,块越大,所支持的 *** 文件和分区越大,也越可能浪费磁盘空间,上表列出的数据基于 4K 的块大小。

代码规模

从代码规模可以看出文件系统的功能丰富程度以及复杂度,下面列出的数据来自于 kernel-4.1-rc8,只是简单的用 wc - l 来统计,没有过滤空行、注释等。

文件系统源文件 (.c) 头文件(.h)ext283631016ext3164961567ext4446504522XFS8960515091Btrfs1052547933

Btrfs 还在快速的开发过程中,代码行数可能还有比较大的变化

XFS 和 Btrfs 都使用了 B -tree

ext2

ext 的优点是比较简单,文件比较少时性能较好,比较适合文件少的场景,主要缺点如下

inode 的数量是固定不变的,在格式化分区的时候可以指定 inode 和数据块所占空间的比例,但一旦格式化好,后续就没法再改变了

当块大小为 4K 时,单个文件大小不能超过 2TB,分区大小不能超过 16TB(目前硬盘大小一般都只有几 TB,所以也不是什么大问题,)

一个目录下最多只能有 32000 个子目录

由于目录里面存储的文件和子目录都是以线性方式来组织的,所以遍历目录效率不高,尤其当目录下文件个数达到 10K 以上规模的时候,速度会明显的变慢

当底层的磁盘分区空间变大时(使用 LVM 时很常见),ext2 没法动态的扩展来使用增加的空间

没有日志 (Journal) 功能,所以数据的安全性不高

ext3

ext3 在 ext2 的基础上实现了下面几个功能,其它的都保持不变,即 ext2 的缺点 ext3 也有

支持日志 (Journal) 功能,数据的安全性较 ext2 有很大的提高

当底层的分区空间变大时,ext3 可以自动扩展来使用增加的空间

使用 HTree 来组织目录里面的文件和子目录,使目录下的文件和子目录数不再受性能限制(数量超过 10K 也不会有性能问题)

ext4

ext4 借鉴了当前成熟的一些文件系统技术,在 ext3 上增加了一些功能,并且对性能做了一些改进,主要变化如下

当块大小为 4K 时,支持的 *** 文件和 *** 分区大小分别达到了 16TB 和 1EB

不再受 32000 个子目录数的限制,支持不限数量的子目录个数

支持 Extents,提高了大文件的操作性能

内部实现上支持一次分配多个数据块,较 ext3 的性能有所提高

支持延时分配(即支持 fallocate 函数)(fallocate 是 libc 的函数,在不支持该功能的文件系统上,libc 会创建一个占用磁盘空间文件)

支持在线快速扫描

支持在线碎片整理(单个文件或者整个分区)

日志 (Journal) 支持校验码(checksum),数据的安全性进一步提高

支持无日志 (No Journaling) 模式(ext3 不支持该功能),这样就和 ext2 一样,消除了写日志对性能的影响

支持纳秒级的时间戳

记录了文件的创建时间,由于相关的应用层工具还不支持,所以只能通过 debug 的方式看到文件的创建时间

这里是一个查看文件 /etc/fstab 创建时间的例子(文件存在 /dev/sda1 分区上):

dev@ubuntu:~$ ls -i /etc/fstab 10747906 /etc/fstab dev@ubuntu:~$ sudo debugfs -R  stat  10747906  /dev/sda1 Inode: 10747906 Type: regular Mode: 0644 Flags: 0x80000 Links: 1 Blockcount: 8 ctime: 0x5546dc54:6e6bc80c -- Sun May 3 22:41:24 2015 atime: 0x55d1b014:8bcf7b44 -- Mon Aug 17 05:57:40 2015 mtime: 0x5546dc54:6e6bc80c -- Sun May 3 22:41:24 2015 crtime: 0x5546dc54:6e6bc80c -- Sun May 3 22:41:24 2015 Size of extra inode fields: 28 EXTENTS: (0):46712815

Extents:在最开始的 ext2 文件系统中,数据块都是一个一个单独管理的,inode 中存有指向数据块的指针,文件占用了多少个数据块,inode 里面就有多少个指针(多级),想象一下一个 1G 的文件,4K 的块大小,那么需要(1024 * 1024)/4=262144 个数据块,即需要 262144 个指针,创建文件的时候需要初始化这些指针,删除文件的时候需要回收这些指针,影响性能。现代的文件系统都支持 Extents 的功能,简单点说,Extent 就是数据块的集合,以前一次分配一个数据块,现在可以一次分配一个 Extent,里面包含很多数据块,同时 inode 里面只需要分配指向 Extent 的指针就可以了,从而大大减少了指针的数量和层级,提高了大文件操作的性能。

inode 数量固定:在 ext2/3/ 4 系列的文件系统中,inode 的数量都是固定的,坏处是如果存很多小文件的话,有可能造成 inode 被用光,但磁盘还有很多剩余空间无法被使用的情况,不过它也有一个好处,就是一旦磁盘损坏,恢复起来要相对简单些,因为数据在磁盘上布局相对要固定简单。

xfs

和 ext4 相比,xfs 不支持下面这些功能

不支持日志 (Journal) 校验码

不支持无日志 (No Journaling) 模式

不支持文件创建时间

不支持数据日志(data journal),只有元数据日志(metadata journal)

但 xfs 有下面这些特性

支持的 *** 文件和分区都达到了 8EB

inode 动态分配,从而不受 inode 数量的限制,再也不用担心存储大量小文件导致 inode 不够用的问题了。

更大的 xattr(extended attributes)空间,ext2/3/ 4 及 btrfs 都限制 xattr 的长度不能超过一个块(一般是 4K),而 xfs 可以达到 64K

内部采用 Allocation groups 机制,各个 group 之间没有依赖,支持并发操作,在多核环境的某些场景下性能表现不错

提供了原生的 dump 和 restore 工具,并且支持在线 dump

btrfs

btrfs 是一个和 ZFS 类似的文件系统,支持的功能非常多,据说将来会替换 ext4 成为 Linux 下的默认文件系统。这里列举一些重要的功能

支持的 *** 文件和分区达到了 16EB

支持 COW(copy on write)

针对小文件和 SSD 做了优化

inode 动态分配

支持子分区(Subvolumes),子分区可以单独挂载

支持元数据和数据的校验(crc32)

支持压缩,去重

支持多个磁盘和分区,可动态扩展

支持 LVM,RAID 的功能(有了 btrfs,就不再需要 lvm 和软 raid 了)

增量备份和恢复

支持快照

将 ext2/3/ 4 转换成 btrfs(反过来不行)

btrfs*** 的缺点就是由于其 COW 的实现方式,导致碎片化问题比较严重,不太适合频繁写的场景,比如数据库、虚拟机的磁盘文件等。不过大部分场合不需要担心,btrfs 有在线的碎片整理工具。

如何选择

下表仅供参考

文件系统适用场景原因 ext2U 盘 U 盘一般不会存很多文件,且 U 盘的文件在电脑上有备份,安全性要求没那么高,由于 ext2 不写日志(journal),所以写 U 盘性能比较好。当然由于 ext2 的兼容性没有 fat 好,目前大多数 U 盘格式还是用 fatext3 对稳定性要求高的地方有了 ext4 后,好像没什么原因还要用 ext3,ext4 现在的问题是出来时间不长,还需要一段时间变稳定 ext4 小文件较少 ext 系列的文件系统都不支持 inode 动态分配,所以如果有大量小文件需要存储的话,不建议用 ext4xfs 小文件多或者需要大的 xttr 空间,如 openstack swift 将数据文件的元数据放在了 xttr 里面 xfs 支持 inode 动态分配,所以不存在 inode 不够的情况,并且 xttr 的 *** 长度可以达到 64Kbtrfs 没有频繁的写操作,且需要 btrfs 的一些特性 btrfs 虽然还不稳定,但支持众多的功能,如果你需要这些功能,且不会频繁的写文件,那么选择 btrfs

另外,ext 系列文件系统内部结构相对简单一些,出问题后恢复相对容易。

感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享的“Linux 下常见文件系统的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,更多相关知识等着你来学习!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-25发表,共计3912字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)