1 Linux 中文件系统的概述 #
SUSE Linux Enterprise Server 随附了不同的文件系统供您选择,包括 Btrfs、Ext4、Ext3、Ext2 和 XFS。每个文件系统都有各自的优点和缺点。有关 SUSE Linux Enterprise Server 中主要文件系统的并排功能比较,请参见 https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP3/#file-system-comparison (Comparison of supported file systems)。本章概述了这些文件系统的工作原理以及它们的优点。
在 SUSE Linux Enterprise 12 中,Btrfs 是操作系统的默认文件系统,XFS 是所有其他使用案例的默认文件系统。此外,SUSE 仍继续支持 Ext 系列的文件系统以及 OCFS2。根据默认设置,Btrfs 文件系统将设置为使用子卷。对于使用 snapper 基础架构的根文件系统,将会自动启用快照。有关 snapper 的详细信息,请参见第 10 章 “通过 Snapper 进行系统恢复和快照管理”。
专业的高性能设置可能需要高可用性的存储系统。为符合高性能群集案例的要求,SUSE Linux Enterprise Server 在 High Availability Extension 附加产品中加入了 OCFS2(Oracle Cluster File System 2) 与 Distributed Replicated Block Device (DRBD)。本指南中不涉及这些高级存储系统的内容。有关信息,请参见 Administration Guide for the SUSE Linux Enterprise High Availability Extension.
记住一点很重要:没有任何一种文件系统适合所有种类的应用。每个文件系统都有各自的特定优点和缺点,必须将这些因素考虑在内。此外,即使是最复杂的文件系统也不能替代合理的备份策略。
本节中使用的术语数据完整性和数据一致性并不是指用户空间数据(您的应用程序写入其文件的数据)的一致性。此数据是否一致必须由应用程序本身控制。
除非本节特别指明,否则设置或更改分区以及文件系统所需的一切步骤,都可以使用 YaST 分区程序(强烈推荐使用)来执行。有关信息,请参见第 10 章 “。 ”
1.1 术语 #
- 元数据
文件系统内部的一种数据结构。它可确保磁盘上的所有数据都有条不紊,并且可供访问。几乎每一种文件系统都有自己的元数据结构,这也是文件系统展现出不同性能特性的原因所在。维护元数据的完整性非常重要,因为如果不这样,则可能无法访问文件系统中的所有数据。
- inode
文件系统的数据结构包含文件的各种信息,包括大小、链接数量、实际存储文件内容的磁盘块的指针、创建、修改和访问的日期与时间。
- 日志
在提及文件系统时,日志是包含某种日志的磁盘上结构,文件系统将要对文件系统的元数据进行的更改存储在此日志中。日志可大大降低文件系统的恢复时间,因为有了它就不需要在系统启动时执行文件系统全面检查这一冗长的搜索程序。而只是重放日志。
1.2 Btrfs #
Brtfs 是由 Chris Mason 开发的一种写时复制 (COW) 文件系统。它基于 Ohad Rodeh 开发的适用于 COW 的 B 树。Btrfs 是日志记录样式的文件系统。它不记录块更改,而是将块更改写入新位置,然后链接上更改。新更改在上一次写后才提交。
1.2.1 主要功能: #
Btrfs 提供容错、修复和易于管理的功能,比如:
可写快照,允许应用更新后按需轻松回滚系统或允许备份文件。
子卷支持:Btrfs 会在为其指派的空间池中创建默认子卷。它允许您在相同空间池中创建更多的子卷,作为不同的文件系统。子卷的数目仅受分配给池的空间所限。
Btrfs 命令行工具中提供了在线检查和修复功能
scrub
。它会在假设树状结构没有问题的前提下,验证数据和元数据的完整性。您可以在安装的文件系统上定期运行 scrub;正常操作期间,它将在后台运行。不同 RAID 级别,适用于元数据和用户数据。
用于元数据和用户数据的不同校验和,可改进错误检测。
与 Linux 逻辑卷管理器 (LVM) 存储对象集成。
与 SUSE Linux Enterprise Server 上的 YaST 分区程序及 AutoYaST 整合。这还包括在多个设备 (MD) 和设备映射程序 (DM) 存储配置上创建 Btrfs 文件系统。
从现有的 Ext2、Ext3 以及 Ext4 文件系统进行脱机迁移。
/boot
的引导加载程序支持,允许从 Btrfs 分区引导。SUSE Linux Enterprise Server }15 SP5 中的 RAID0、RAID1 和 RAID10 配置文件支持多卷 Btrfs。更高的 RAID 级别尚不受支持,但安装将来发布的服务包后可能会支持。
使用 Btrfs 命令设置透明压缩。
1.2.2 SUSE Linux Enterprise Server 上的根文件系统设置 #
SUSE Linux Enterprise Server 默认设置为对根分区使用 Btrfs 和快照。快照可让您在应用更新之后有需要时轻松地回滚系统,也可让您备份文件。快照可通过 SUSE Snapper 基础架构轻松管理,如第 10 章 “通过 Snapper 进行系统恢复和快照管理”所述。有关 SUSE Snapper 项目的一般信息,请参见 OpenSUSE.org (http://snapper.io) 上的 Snapper 门户网站 Wiki。
使用快照回滚系统时,必须确保在回滚期间,数据(例如用户的主目录、Web 和 FTP 服务器内容或日志文件)不会遗失或被重写。这一点通过使用根文件系统上的 Btrfs 子卷实现。子卷可从快照中排除。安装期间,根据 YaST 建议,SUSE Linux Enterprise Server 上的默认根文件系统设置包含下列子卷。由于以下原因,它们会从快照中排除。
/boot/grub2/i386-pc
、/boot/grub2/x86_64-efi
、/boot/grub2/powerpc-ieee1275
、/boot/grub2/s390x-emu
不能回滚引导加载程序配置。上面列出的目录是架构专属目录。前两个目录位于 AMD64/Intel 64 计算机上,后两个目录分别位于 IBM POWER 和 IBM Z 上。
/home
如果独立的分区中没有
/home
,便会将该目录排除以免在回滚时发生数据丢失。/opt
第三方产品通常安装到
/opt
下。排除此目录是为了防止在回滚时卸装这些应用程序。/srv
包含 Web 和 FTP 服务器的数据。排除此目录是为了防止在回滚时发生数据丢失。
/tmp
包含临时文件和缓存的所有目录都会排除在快照范围之外。
/usr/local
在手动安装软件时会用到此目录。系统会将该目录排除以免在回滚时卸载这些安装的软件。
/var
此目录包含许多变量文件(包括日志、暂时缓存、
/var/opt
中的第三方产品),是虚拟机映像和数据库的默认位置。因此,创建此子卷是为了从快照中排除所有这些变量数据,且已禁用“写入时复制”。
仅当您未移除任何预先配置的子卷时,SUSE 才支持回滚。不过,您可以使用 YaST 分区程序添加子卷。
1.2.2.1 挂载压缩的 Btrfs 文件系统 #
Btrfs 文件系统支持透明压缩。如果启用,Btrfs 将在写入时压缩文件数据,并在读取时解压缩文件数据。
使用 compress
或 compress-force
挂载选项,并选择压缩算法 zstd
、lzo
或 zlib
(默认)。zlib 压缩的压缩率更高,而 lzo 的压缩速度更快,并且所需的 CPU 负载更小。zstd 算法提供了一种新式折衷方案,其性能接近 lzo,而压缩率与 zlib 类似。
例如:
#
mount -o compress=zstd /dev/sdx /mnt
如果您创建了一个文件并在其中写入数据,而压缩后的结果大于或等于未压缩时的大小,则将来针对此文件执行写入操作后,Btrfs 会始终跳过压缩。如果您不希望有这种行为,请使用 compress-force
选项。对于包含一些初始不可压缩数据的文件而言,此选项可能很有用。
请注意,压缩只会作用于新文件。如果使用 compress
或 compress-force
选项挂载文件系统,则在未压缩的情况下写入的文件将不会压缩。此外,包含 nodatacow
属性的文件的内容永远不会压缩:
#
chattr
+C FILE#
mount
-o nodatacow /dev/sdx /mnt
加密与任何压缩操作均无关。在此分区中写入一些数据后,请打印细节:
#
btrfs filesystem show /mnt
btrfs filesystem show /mnt
Label: 'Test-Btrfs' uuid: 62f0c378-e93e-4aa1-9532-93c6b780749d
Total devices 1 FS bytes used 3.22MiB
devid 1 size 2.00GiB used 240.62MiB path /dev/sdb1
如果您希望此设置是永久性的,请在 /etc/fstab
配置文件中添加 compress
或 compress-force
选项。例如:
UUID=1a2b3c4d /home btrfs subvol=@/home,compress 0 0
1.2.2.2 挂载子卷 #
在 SUSE Linux Enterprise Server 上,从快照进行系统回滚的程序通过先从快照引导来执行。这样一来,您便可以在运行回滚之前,在运行的同时检查快照。只要挂载子卷,就可以实现从快照引导(通常没必要)。
除了第 1.2.2 节 “SUSE Linux Enterprise Server 上的根文件系统设置”中列出的子卷之外,系统中还存在一个名为 @
的卷。这是默认的子卷,将挂载为根分区 (/
)。其他子卷将挂载到此卷中。
从快照引导时,使用的不是 @
子卷,而是快照。快照中包括的文件系统部分将以只读方式挂载为 /
。其他子卷将以可写入方式挂载到快照中。此状态默认为临时状态,下次重引导时将还原先前的配置。要使其变为永久状态,请执行 snapper
rollback
命令。这将使目前引导的快照成为新的默认子卷,在重引导之后将会使用它。
1.2.2.3 检查可用空间 #
通常可通过运行 df
命令来检查文件系统的用量。在 Btrfs 文件系统上,df
的输出可能有误导性,因为除了原始数据分配的空间以外,Btrfs 文件系统还会为元数据分配并使用空间。
因此,即使看上去仍有大量的可用空间,Btrfs 文件系统也可能会报告空间不足。发生这种情况时,为元数据分配的全部空间都已用尽。使用以下命令可检查 Btrfs 文件系统上已用和可用的空间:
btrfs filesystem show
>
sudo
btrfs filesystem show / Label: 'ROOT' uuid: 52011c5e-5711-42d8-8c50-718a005ec4b3 Total devices 1 FS bytes used 10.02GiB devid 1 size 20.02GiB used 13.78GiB path /dev/sda3显示文件系统的总大小及其用量。如果最后一行中的这两个值匹配,则表示文件系统上的全部空间都已分配出去。
btrfs filesystem df
>
sudo
btrfs filesystem df / Data, single: total=13.00GiB, used=9.61GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=768.00MiB, used=421.36MiB GlobalReserve, single: total=144.00MiB, used=0.00B显示文件系统的已分配 (
total
) 空间和已用空间值。如果元数据的total
和used
值基本上相等,则表示元数据的全部空间都已分配出去。btrfs filesystem usage
>
sudo
btrfs filesystem usage / Overall: Device size: 20.02GiB Device allocated: 13.78GiB Device unallocated: 6.24GiB Device missing: 0.00B Used: 10.02GiB Free (estimated): 9.63GiB (min: 9.63GiB) Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 144.00MiB (used: 0.00B) Data Metadata System Id Path single single single Unallocated -- --------- -------- --------- -------- ----------- 1 /dev/sda3 13.00GiB 768.00MiB 32.00MiB 6.24GiB -- --------- -------- --------- -------- ----------- Total 13.00GiB 768.00MiB 32.00MiB 6.24GiB Used 9.61GiB 421.36MiB 16.00KiB显示类似于前两个命令输出合并所得的数据。
有关更多信息,请参见 man 8 btrfs-filesystem
和 https://btrfs.wiki.kernel.org/index.php/FAQ。
1.2.3 从 ReiserFS 和 ext 文件系统迁移到 Btrfs #
您可以使用 btrfs-convert
工具,将数据卷从现有 ReiserFS 或 Ext(Ext2、Ext3 或 Ext4)迁移到 Btrfs 文件系统。该过程允许您对未挂载(脱机)的文件系统进行就地转换,执行此操作可能需要使用包含 btrfs-convert
工具的可引导安装媒体。该工具会在原始文件系统的可用空间内构建 Btrfs 文件系统,并直接链接到其中包含的数据。设备上必须有足够用于创建元数据的可用空间,否则转换将失败。原始文件系统将保持不变,Btrfs 文件系统不会占用任何可用空间。需要的空间大小取决于文件系统的内容,可能会因其中包含的文件系统对象(例如文件、目录、扩展属性)数量而异。由于系统会直接参照数据,文件系统上的数据量不会影响转换所需的空间,但使用尾部封装且大小超过 2 KiB 的文件除外。
不支持将根文件系统转换为 Btrfs,且不建议这样做。由于需要根据您的特定设置定制各种步骤,因此无法自动完成此类转换 — 该过程需要经过复杂的配置才能提供正确的回滚,/boot
必须位于根文件系统上,并且系统必须包含特定的子卷,等等。请保留现有的文件系统,或者从头开始重新安装整个系统。
要将原始文件系统转换为 Btrfs 文件系统,请运行:
#
btrfs-convert /path/to/device
/etc/fstab
转换后,需确保 /etc/fstab
中对原始文件系统的所有参照都已调整,现指示设备包含 Btrfs 文件系统。
转换后,Btrfs 文件系统的内容将会反映源文件系统的内容。源文件系统将一直保留,直到您去除了在 fs_root/reiserfs_saved/image
中创建的相关只读映像为止。该映像文件实际上是转换前 ReiserFS 文件系统的一个“快照”,修改 Btrfs 文件系统时不会修改该映像。要去除该映像文件,请去除 reiserfs_saved
子卷:
#
btrfs subvolume delete fs_root/reiserfs_saved
要将文件系统还原到原始文件系统,请使用以下命令:
#
btrfs-convert -r /path/to/device
您在文件系统装载为 Btrfs 文件系统时所做的任何更改都将丢失。切勿在此期间执行任何平衡操作,否则将无法正确恢复文件系统。
1.2.4 Btrfs 管理 #
Btrfs 与 YaST 分区程序和 AutoYaST 集成。您可以在安装期间使用它来为根文件系统建立解决方案。安装之后,您可以使用 YaST 分区程序来查看和管理 Btrfs 卷。
btrfsprogs
软件包中提供了 Btrfs 管理工具。有关使用 Btrfs 命令的信息,请参见 man 8 btrfs
、man 8
btrfsck
和 man 8 mkfs.btrfs
命令。有关 Btrfs 功能的信息,请参见 Btrfs wiki,网址为 http://btrfs.wiki.kernel.org。
1.2.5 Btrfs 子卷配额支持 #
Btrfs 根文件系统子卷(例如 /var/log
、/var/crash
或 /var/cache
)在正常运作期间可能会使用所有可用的磁盘空间,这会导致系统出现故障。为避免出现此状况,SUSE Linux Enterprise Server 提供了 Btrfs 子卷配额支持。只要根据 YaST 建议设置根文件系统,便可以启用和设置子卷配额。
1.2.5.1 使用 YaST 设置 Btrfs 配额 #
要使用 YaST 为根文件系统的子卷设置配额,请执行以下步骤:
1.2.5.2 在命令行上设置 Btrfs 配额 #
要在命令行上设置根文件系统的子卷配额,请执行以下步骤:
启用配额支持:
>
sudo
btrfs quota enable /取得子卷列表:
>
sudo
btrfs subvolume list /只能为现有子卷设置配额。
为上一步中所列的其中一个子卷设置配额。子卷可以用路径识别(例如
/var/tmp
),也可以用0/SUBVOLUME ID
(例如0/272
)。以下示例为/var/tmp
设置 5 GB 配额。>
sudo
btrfs qgroup limit 5G /var/tmp大小单位可以是字节 (5000000000)、KB (5000000K)、MB (5000M) 或 GB (5G)。以字节为单位生成的值略有不同,因为 1024 字节 = 1 KiB,1024 KiB = 1 MiB,依此类推
若要列出现有配额,请使用以下命令。
max_rfer
列以字节为单位显示配额。>
sudo
btrfs qgroup show -r /
如果您要取消现有配额,请将配额大小设置为 none
:
>
sudo
btrfs qgroup limit none /var/tmp
若要禁用某个分区及其所有子卷的配额支持,请使用 btrfs quota disable
:
>
sudo
btrfs quota disable /
1.2.5.3 更多信息 #
有关细节,请参见 man 8 btrfs-qgroup
和 man 8
btrfs-quota
。Btrfs Wiki (UseCases) 上的 https://btrfs.wiki.kernel.org/index.php/UseCases 页面也提供了更多信息。
1.2.6 Btrfs 上的交换 #
如果源子卷包含任何已启用的交换文件,则您无法创建快照。
如果满足与生成的交换文件相关的以下准则,则 SLES 支持在 Btrfs 文件系统上的文件交换:
交换文件必须有
NODATACOW
和NODATASUM
挂载选项。不得压缩交换文件,您可以通过设置
NODATACOW
和NODATASUM
挂载选项来确保满足此准则。两个选项都会禁用交换文件压缩。在运行排它操作(例如设备调整大小、添加、去除或替换)时,或在运行平衡操作时,不能激活交换文件。
交换文件不能是稀疏文件。
交换文件不能是内联文件。
交换文件必须位于
single
分配配置文件系统上。
1.2.7 Btrfs 发送/接收 #
Btrfs 允许生成快照来捕获文件系统的状态。例如,Snapper 可使用此功能在系统更改之前及之后创建快照,以便允许回滚。不过,将快照与发送/接收功能结合使用还可以在远程位置创建和维护文件系统的副本。例如,此功能可用于执行增量备份。
btrfs send
操作可计算同一子卷中两个只读快照之间的差异,并将差异发送到某个文件或 STDOUT。btrfs receive
操作会接收 send 命令的结果,并将其应用到快照。
1.2.7.1 先决条件 #
要使用发送/接收功能,需要满足以下要求:
源端 (
send
) 和目标端 (receive
) 各有一个 Btrfs 文件系统。Btrfs 发送/接收是对快照执行的,因此,相应的数据需要驻留在 Btrfs 子卷中。
源端中的快照必须为只读模式。
SUSE Linux Enterprise 12 SP2 或更高版本。早期版本的 SUSE Linux Enterprise 不支持发送/接收。
1.2.7.2 增量备份 #
以下过程展示了 Btrfs 发送/接收操作的基本用法,其中示范了如何在 /backup/data
(目标端)中创建 /data
(源端)的增量备份。/data
需为子卷。
在源端创建初始快照(在本示例中名为
snapshot_0
),并确保将它写入该磁盘:>
sudo
btrfs subvolume snapshot -r /data /data/bkp_data sync一个新子卷
/data/bkp_data
即会创建。该子卷将用作后续增量备份的基础,应将它保留为参照。将初始快照发送到目标端。由于这是初始的发送/接收操作,因此需要发送整个快照:
>
sudo
bash -c 'btrfs send /data/bkp_data | btrfs receive /backup'目标端上即会创建一个新子卷
/backup/bkp_data
。
完成初始设置后,可以创建增量备份,并将当前快照与先前快照之间的差异发送到目标端。操作过程始终是相同的:
在源端创建新快照。
将差异发送到目标端。
可选:重命名和/或清理两端中的快照。
在源端创建新快照,并确保将它写入该磁盘。在下面的示例中,快照命名为 bkp_data_CURRENT_DATE:
>
sudo
btrfs subvolume snapshot -r /data /data/bkp_data_$(date +%F) sync创建新子卷,例如
/data/bkp_data_2016-07-07
。将先前快照与您创建的快照之间的差异发送到目标端。为此,可以使用选项
-p SNAPSHOT
指定先前的快照。>
sudo
bash -c 'btrfs send -p /data/bkp_data /data/bkp_data_2016-07-07 \ | btrfs receive /backup'一个新子卷
/backup/bkp_data_2016-07-07
即会创建。如此我们有了四个快照,每端各有两个:
/data/bkp_data
/data/bkp_data_2016-07-07
/backup/bkp_data
/backup/bkp_data_2016-07-07
现在,关于如何继续,您有三种选择:
保留两端中的所有快照。如果采用这种选择,您可以回滚到两端中的任一快照,同时会复制所有数据。不需要执行额外操作。执行后续增量备份时,请记得使用倒数第二个快照作为发送操作的父项。
仅保留源端中的最后一个快照,保留目标端中的所有快照。此外,允许回滚到两端中的任一快照 - 要回滚到源端中的特定快照,请对整个快照执行从目标端到源端的发送/接收操作。在源端执行删除/移动操作。
仅保留两端中的最后一个快照。采用这种方法,您会在目标端创建一个备份,该备份代表源端中生成的最后一个快照的状态。系统无法回滚到其他快照。在源端和目标端执行删除/移动操作。
如果只想保留源端中的最后一个快照,请执行以下命令:
>
sudo
btrfs subvolume delete /data/bkp_data>
sudo
mv /data/bkp_data_2016-07-07 /data/bkp_data第一条命令将删除先前的快照,第二条命令将当前快照重命名为
/data/bkp_data
。这可确保备份的最后一个快照始终命名为/data/bkp_data
。因此,您也可以始终使用此子卷名称作为增量发送操作的父项。如果只想保留目标端中的最后一个快照,请执行以下命令:
>
sudo
btrfs subvolume delete /backup/bkp_data>
sudo
mv /backup/bkp_data_2016-07-07 /backup/bkp_data第一条命令将删除先前的备份快照,第二条命令将当前备份快照重命名为
/backup/bkp_data
。这可确保最新的备份快照始终命名为/backup/bkp_data
。
要将快照发送到远程计算机,请使用 SSH:
>
btrfs send /data/bkp_data | ssh root@jupiter.example.com 'btrfs receive /backup'
1.2.8 数据去重支持 #
Btrfs 支持重复数据删除功能,具体办法是以指向通用存储位置中的块单一副本的逻辑链接替换文件系统中完全相同的块。SUSE Linux Enterprise Server 提供 duperemove
工具来扫描文件系统中有没有完全相同的块。在 Btrfs 文件系统上使用时,也可以用来删除这些重复的块,从而节省文件系统上的空间。duperemove
。要使此功能可用,请安装软件包 duperemove。
如果您要对大量文件去重,请使用 --hashfile
选项:
>
sudo
duperemove--hashfile HASH_FILE
file1 file2 file3
--hashfile
选项会将所有指定文件的哈希存储到 HASH_FILE(而不是 RAM 中),以防耗尽 RAM。HASH_FILE 可重复使用 - 当完成生成基线哈希文件的初始运行后,即可对大型数据集更改去重。
duperemove
可以针对一系列文件操作,也可以以递归方式扫描某个目录:
>
sudo
duperemove OPTIONS file1 file2 file3>
sudo
duperemove -r OPTIONS directory
它有两种操作模式:只读和去重。以只读模式运行时(即不使用 -d
开关),该命令会扫描给定文件或目录中的重复块,并将其列显出来。此模式适用于所有文件系统。
只有 Btrfs 文件系统支持在去重模式下执行 duperemove
。扫描给定文件或目录之后,将会提交重复的块以进行去重。
有关更多信息,请参见man 8 duperemove
。
1.2.9 从根文件系统删除子卷 #
出于特定目的,您可能需要从根文件系统中删除某个默认的 Btrfs 子卷。目的之一是将某个子卷(例如 @/home
或 @/srv
)转换成单独设备上的文件系统。以下过程演示如何删除 Btrfs 子卷:
确定需要删除的子卷(例如
@/opt
)。请注意,根路径始终使用子卷 ID“5”。>
sudo
btrfs subvolume list / ID 256 gen 30 top level 5 path @ ID 258 gen 887 top level 256 path @/var ID 259 gen 872 top level 256 path @/usr/local ID 260 gen 886 top level 256 path @/tmp ID 261 gen 60 top level 256 path @/srv ID 262 gen 886 top level 256 path @/root ID 263 gen 39 top level 256 path @/opt [...]查找托管根分区的设备名称:
>
sudo
btrfs device usage / /dev/sda1, ID: 1 Device size: 23.00GiB Device slack: 0.00B Data,single: 7.01GiB Metadata,DUP: 1.00GiB System,DUP: 16.00MiB Unallocated: 14.98GiB在单独的挂载点(例如
/mnt
)上挂载根文件系统(ID 为 5 的子卷):>
sudo
mount -o subvolid=5 /dev/sda1 /mnt从挂载的根文件系统中删除
@/opt
分区:>
sudo
btrfs subvolume delete /mnt/@/opt卸载以前挂载的根文件系统:
>
sudo
umount /mnt
1.3 XFS #
SGI 在 20 世纪 90 年代初开始开发 XFS,最初计划将 XFS 作为 IRIX OS 的文件系统。开发 XFS 的目的是创建一个高性能的 64 位日志文件系统来满足对计算能力的极高要求。XFS 适合操纵大型文件,在高端硬件上表现优异。XFS 是 SUSE Linux Enterprise Server 中数据分区的默认文件系统。
快速回顾 XFS 的关键功能可解释为什么此文件系统经证明在高端计算方面是其他日志文件系统的强大竞争对手。
- 高可伸缩性
XFS 使用分配组来提供高可伸缩性
在创建 XFS 文件系统时,文件系统底层的块设备被分成 8 个或 8 个以上相同大小的线性区域。这些区域称为分配组。每个分配组管理自己的 inode 和可用空间。实际上,可以将分配组看作文件系统中的文件系统。因为分配组相互独立,所以内核可同时对多个分配组进行寻址。此功能是 XFS 优异的可伸缩性关键之所在。独立分配组的概念自然适合多处理器系统的需要。
- 性能较高
XFS 通过有效管理磁盘空间来提供高性能
可用空间和 inode 是由分配组内的 B+ 树处理的。使用 B+ 树将大大增强 XFS 的性能和可伸缩性。XFS 使用延迟分配,它可以通过将进程分为两部分而处理分配。将挂起事务存储在 RAM 中并保留适当数量的空间。XFS 仍不决定应存储数据的准确位置(即不指出文件系统块)。此决定将被延迟到最后的时刻。某些生存期很短的临时数据可能永远不会被存储到磁盘上,这是因为在 XFS 决定保存它们的位置时,这些数据已经过时。以这种方式,XFS 增强了写性能并减少了文件系统分段。因为延迟分配引起写事件的频率比其他文件系统引起写事件的频率要低,所以如果写操作期间发生系统崩溃,则数据丢失可能会更加严重。
- 进行预分配以避免文件系统碎片
在将数据写入文件系统前,XFS 保留(预分配)文件所需的可用空间。这样会大大减少文件系统碎片的数目。因为文件的内容不会分散在整个文件系统中,所以性能得以提高。
1.3.1 XFS 格式 #
SUSE Linux Enterprise Server 支持 XFS 文件系统的“磁盘格式” (v5)。这种格式的主要优点包括,所有 XFS 元数据的自动检查总数、文件类型支持以及支持文件更多数量的访问控制列表。
请注意,低于 3.12 版的 SUSE Linux Enterprise 内核、低于 3.2.0 版的 xfsprogs
以及在 SUSE Linux Enterprise 12 之前发布的 GRUB 2 版本均不支持这种格式。
XFS 即将弃用采用 V4 格式的文件系统。此文件系统格式是由以下命令创建的:
mkfs.xfs -m crc=0 DEVICE
该格式在 SLE 11 和更低版本中使用,目前它通过 dmesg
创建警告消息:
Deprecated V4 format (crc=0) will not be supported after September 2030
如果您在 dmesg
命令的输出中看到上述消息,建议将文件系统更新到 V5 格式:
将数据备份到另一台设备。
在该设备上创建文件系统。
mkfs.xfs -m crc=1 DEVICE
从已更新的设备上的备份恢复数据。
1.4 Ext2 #
Ext2 的原身可以追溯到 Linux 历史的早期。其前身是“扩展文件系统”,于 1992 年 4 月实施,集成在 Linux 0.96c 中。扩展文件系统经历了数次修改,后来才称为 Ext2,曾经是多年来最受欢迎的 Linux 文件系统。但随着日志文件系统的创建以及其恢复时间的缩短,Ext2 的重要性逐渐降低。
简要总结 Ext2 的优点有助于您了解为什么它以前是(在某些领域现在仍是)许多 Linux 用户最喜欢使用的 Linux 文件系统。
- 可靠性和速度
Ext2 是一个“老古董”,它经历了许多改进和频繁的测试。这可能是人们经常称之为坚如磐石的文件系统的原因。在系统中断后,如果无法彻底卸装文件系统,则 e2fsck 将开始分析文件系统数据。系统使元数据恢复一致的状态,并将挂起的文件或数据块写入指定的目录(名为
lost+found
)。与日志文件系统相比,e2fsck 会分析整个文件系统,而不仅仅是元数据中最近修改的位。这种操作所花的时间要远远超过检查日志文件系统的日志数据所花的时间。根据文件系统的大小,此过程可能需要半小时或更长时间。因此,对于任何要求高可用性的服务器,不要选择 Ext2。但是,因为 Ext2 不维护日志且使用的内存也更少,所以其速度往往快于其他文件系统。- 可方便地升级
因为 Ext3 以 Ext2 代码为基础并且共享 Ext2 的磁盘上格式和元数据格式,所以从 Ext2 升级到 Ext3 非常容易。
1.5 Ext3 #
Ext3 由 Stephen Tweedie 设计。与所有其他下一代文件系统不同,Ext3 并没有采用全新的设计原则。它是在 Ext2 的基础上设计的。这两个文件系统密切关联。可以方便地在 Ext2 文件系统上建立 Ext3 文件系统。Ext2 和 Ext3 最重要的区别是 Ext3 支持日志。总之,Ext3 有三个主要优点:
1.5.1 可方便并高度可靠地从 ext2 升级 #
Ext2 的代码为 Ext3 奠定了坚实的基础,使后者成为受到高度评价的下一代文件系统。在 Ext3 中,它的可靠性和稳定性与日志文件系统的优点完美地结合在一起。不像转换至其他日志文件系统(例如 XFS)那么费时(备份整个文件系统,然后从头开始重新创建),转换到 Ext3 只需几分钟时间。升级到 Ext3 还很安全,因为从头重新创建整个文件系统可能会出现问题。考虑到等待升级到日志文件系统的现有 Ext2 系统的数量,就很容易明白为什么 Ext3 对许多系统管理员来说如此重要。从 Ext3 降级到 Ext2 与升级一样简单。将 Ext3 文件系统完全卸载,然后重新挂载成 Ext2 文件系统即可。
1.5.2 将 ext2 文件系统转换为 ext3 #
要将 Ext2 文件系统转换为 Ext3:
以
root
用户身份运行tune2fs -j
来创建 Ext3 日志。此命令将用默认参数创建 Ext3 日志。
要指定日志的大小和存放它的设备,请改为运行
tune2fs
-J
,同时使用所需的日志选项size=
和device=
。有关tune2fs
程序的详细信息,请参见tune2fs
手册页。以
root
用户身份编辑文件/etc/fstab
,将为相应分区指定的文件系统类型从ext2
更改为ext3
,然后保存更改。这确保可以正确识别出 Ext3 文件系统。此更改将在下次重引导后生效。
若引导已设置为 Ext3 分区的根文件系统,请在
initrd
中添加模块ext3
和jbd
。操作步骤如下:打开或创建
/etc/dracut.conf.d/filesystem.conf
,并添加如下一行(请注意前导空格):force_drivers+=" ext3 jbd"
然后运行
dracut
-f
命令。
重新启动系统。
1.6 Ext4 #
2006 年,Ext4 做为 Ext3 的传承面市。它是扩展的文件系统版本中的最新文件系统。Ext4 最初旨在增大存储大小,它支持最大大小为 1 EiB 的卷、最大大小为 16 TiB 的文件和无限个子目录。Ext4 使用区域(而不是传统的直接和间接块指针)来映射文件内容。使用区域可以改善在磁盘中存储数据以及从中检索数据的功能。
Ext4 还引入了多项性能增强功能,例如延迟块分配和速度大幅加快的文件系统检查例程。Ext4 还支持日志校验和,并可提供以纳秒度量的时间戳,因而更加可靠。Ext4 完全反向兼容于 Ext2 和 Ext3,后两个文件系统都可以作为 Ext4 挂载。
Ext4 内核模块中的 Ext4 驱动程序完全支持 Ext3 功能。
1.6.1 可靠性和性能 #
某些其他日志文件系统采用“仅元数据”的日志方法。这意味着元数据始终保持一致的状态,但无法自动保证文件系统数据本身一致。Ext4 的设计既可以照顾到元数据,又可以照顾到数据。“照顾”的程度可以自定义。以 data=journal
模式挂载 Ext4 可以提供最高安全性(数据完整性),但由于要将元数据和数据都记入日志,因此可能会降低系统速度。另一种方法是使用 data=ordered
模式,此模式可确保数据和元数据的完整性,但只对元数据使用日志。文件系统驱动程序收集与一次元数据更新对应的所有数据块。这些数据块在更新元数据之前被写入磁盘中。这样,在不牺牲性能的情况下,元数据和数据的一致性得以实现。可使用的第三个挂载选项是 data=writeback
,它允许数据在其元数据已经提交至日志后再写入主要文件系统。在性能方面,此选项常被认为是最佳选项。但它在维护内部文件系统完整性的同时,允许以前的数据在系统崩溃并恢复后再次出现在文件中。Ext4 使用 data=ordered
选项作为默认值。
1.6.2 Ext4 文件系统 inode 大小及 inode 数量 #
inode 用于存储文件的相关信息及其在文件系统中的块位置。为了让 inode 有空间可以容纳扩展属性以及 ACL,默认的 inode 大小已增大至 256 字节。
当您创建新的 Ext4 文件系统时,系统将根据可创建的 Inode 总数预先分配 Inode 表格中的空间。每 inode 的字节数比率以及文件系统的大小决定了可以创建的 inode 数量。建立文件系统时,将根据每 inode 字节数的单位空间创建 inode:
number of inodes = total size of the file system divided by the number of bytes per inode
inode 的数量控制着文件系统中可容纳的文件数:一个文件对应一个 inode。
inode 分配完毕后,将无法更改 inode 大小的设置或每 inode 的字节数比率。如果不使用其他设置重新创建文件系统,或不扩展文件系统,则无法添加 Inode。超过 inode 最大数量时,只有删除部分文件才能在文件系统上创建新文件。
新建 Ext4 文件系统时,您可以指定 inode 大小和每 inode 的字节数比率,以控制文件系统上可容纳 inode 空间占用量以及文件数量。如果未指定块大小、inode 大小以及每 inode 的字节数比率值,则将应用 /etc/mked2fs.conf
文件中的默认值。有关信息,请参见 mke2fs.conf(5)
手册页。
使用以下指标:
inode 大小:: 默认的 inode 大小为 256 字节。指定字节值,即介于 128 字节(含)到块大小(含)之间的 2 的乘方值,如 128、256、512,以此类推。只有当 Ext4 文件系统上不使用扩展属性或 ACL 时才可使用 128 字节。
每 inode 的字节数比率:: 默认的每 inode 的字节数比率为 16384 字节。有效的每 inode 的字节数比率值必须是大于等于 1024 字节的 2 的乘方值,如 1024、2048、4096、8192、16384、32768,以此类推。该值不应小于文件系统的块大小,因为块大小是用于存储数据的最小空间大块。Ext4 文件系统的默认块大小为 4 KiB。
此外,请考虑需要存储的文件数量及大小。例如,如果您的文件系统上将会有许多小文件,则可以指定一个较小的每 inode 的字节数比率,这样会增加 inode 的数量。如果文件系统将存储超大型文件,您可以指定一个较大的每 Inode 的字节数比率,这样可减少可能的 Inode 数。
通常情况下,最好要保证有足够多的 inode 可供使用。如果 inode 数量过少且文件很小,则可能当磁盘上的文件数量已达最大值时实际上磁盘却还很空。如果 inode 过多且文件很大,则可能虽然报告仍有可用空间,但却无法使用,这是因为您无法在为 inode 预留的空间中新建文件。
使用以下任何一种方法设置 inode 大小以及每 inode 的字节数比率:
修改所有新 Ext4 文件系统的默认设置:: 在文本编辑器中,修改
/etc/mke2fs.conf
文件的defaults
部分,将inode_size
和inode_ratio
设置为所需的默认值。这些值将应用到所有新的 Ext4 文件系统。例如:blocksize = 4096 inode_size = 128 inode_ratio = 8192
在命令行处:: 在创建新的 Ext4 文件系统时,将 inode 大小 (
-I 128
) 以及每 inode 的字节数比率 (-i 8192
) 传递给mkfs.ext4(8)
命令或mke2fs(8)
命令。例如,使用以下任一命令:>
sudo
mkfs.ext4 -b 4096 -i 8092 -I 128 /dev/sda2>
sudo
mke2fs -t ext4 -b 4096 -i 8192 -I 128 /dev/sda2在使用 YaST 安装期间:: 在安装期间,新建 Ext4 文件系统时要传递 inode 大小和每 inode 的字节数比率值。在 中选择分区,然后单击 。在 下,选择 ,然后单击 。在 对话框中,从 、 和 下拉框中选择所需的值。
例如,在
下拉框中选择 4096、在 下拉框中选择 8192、在 下拉框中选择 128,然后单击 。
1.6.3 升级到 Ext4 #
在对文件系统执行任何更新之前,请备份文件系统上的所有数据。
要从 Ext2 或 Ext3 进行升级,必须启用以下功能:
Ext4 所需的功能 #- extents
硬盘上的邻接块,用于使文件彼此相连并防止出现碎片
- unint_bg
迟缓 inode 表初始化
- dir_index
针对大目录的哈希 b 树查找
- 在 Ext2 上:
as_journal
在 Ext2 文件系统上启用日志。
要启用这些功能,请运行:
在 Ext3 上:
#
tune2fs -O extents,uninit_bg,dir_index DEVICE_NAME在 Ext2 上:
#
tune2fs -O extents,uninit_bg,dir_index,has_journal DEVICE_NAME
以
root
身份编辑/etc/fstab
文件:将ext3
或ext2
记录更改为ext4
。此更改将在下次重引导后生效。要引导 Ext4 分区上设置的文件系统,请在
initramfs
中添加模块ext4
和jbd
。打开或创建/etc/dracut.conf.d/filesystem.conf
并添加下面一行:force_drivers+=" ext4 jbd"
需要通过运行以下命令来重写现有的 dracut
initramfs
:dracut -f
重引导系统。
1.7 ReiserFS #
SUSE Linux Enterprise Server 15 中完全去除了 ReiserFS 支持。要将现有分区迁移到 Btrfs,请参见第 1.2.3 节 “从 ReiserFS 和 ext 文件系统迁移到 Btrfs”。
1.8 OpenZFS 和 ZFS #
OpenZFS 和 ZFS 文件系统都不受 SUSE 的支持。ZFS 是一个闭源文件系统,因此不可由 SUSE 使用。用于约束 OpenZFS 的 CDDL 许可证与 GPL 许可证不兼容。但是,Btrfs 相应地为 OpenZFS 提供了一个优异的替代方案。ZFS 完全受 SUSE 的支持。
1.9 其他受支持的文件系统 #
表 1.1 “Linux 中的文件系统类型”对 linux 支持的其他一些文件系统进行了总结。支持这些文件系统主要是为了确保与不同类型的媒体或异操作系统实现兼容和数据交换。
文件系统类型 |
说明 |
---|---|
|
CD-ROM 上的标准文件系统。 |
|
|
|
网络文件系统:在此文件系统中,可以将数据存储在网络中的任何计算机上,并可以通过网络授予访问权限。 |
|
Windows NT 文件系统;只读。 |
|
为使用闪存(例如 USB 闪存盘和 SD 卡)而优化的文件系统。 |
|
Windows 等产品使用服务器消息块来支持通过网络启用文件访问。 |
|
供 BSD、SunOS 和 NextStep 使用。只在只读方式下支持此文件系统。 |
|
MS-DOS 上的 Unix:在标准 |
|
虚拟 FAT: |
1.10 已阻止的文件系统 #
出于安全原因,已阻止某些文件系统自动挂载。这些文件系统通常不再受到维护,并且不太常用。但是,可以装载这些文件系统的内核模块,因为内核中 API 仍是兼容的。将用户可挂载的文件系统和可卸设备上自动挂载的文件系统结合使用可能会导致非特权用户触发内核模块自动装载,并可能导致可卸设备存储潜在恶意的数据。
要获取不允许自动挂载的文件系统列表,请运行以下命令:
>
sudo
rpm -ql suse-module-tools | sed -nE 's/.*blacklist_fs-(.*)\.conf/\1/p'
如果您尝试使用 mount
命令挂载包含已阻止文件系统的设备,该命令将输出错误消息,例如:
mount: /mnt/mx: unknown filesystem type 'minix' (hint: possibly blacklisted, see mount(8)).
要允许挂载文件系统,需要从阻止列表中去除特定的文件系统。每个已阻止的文件系统都有各自的配置文件,例如,efs
的配置文件是 /lib/modules.d/60-blacklist_fs-efs.conf
。但是,请不要编辑这些文件,因为每当更新软件包 suse-module-tools
时,就会重写这些文件。要允许自动挂载已阻止的文件系统,可使用以下选项:
创建指向
/dev/null
的符号链接,例如,对于 efs 文件系统,请使用以下命令:>
sudo
ln -s /dev/null /etc/modules.d/60-blacklist_fs-efs.conf将配置文件复制到
/etc/modprobe.d
:>
sudo
cp /lib/modules.d/60-blacklist_fs-efs.conf /etc/modprobe.d/60-blacklist_fs-efs.conf在配置文件中注释掉以下语句:
# blacklist omfs
即使无法自动挂载某个文件系统,您也可以直接使用 modprobe
装载该文件系统的相应内核模块:
>
sudo
modprobe FILESYSTEM
例如,对于 cramfs
文件系统,输出如下所示:
unblacklist: loading cramfs file system module unblacklist: Do you want to un-blacklist cramfs permanently (<y>es/<n>o/n<e>ver)? y unblacklist: cramfs un-blacklisted by creating /etc/modprobe.d/60-blacklist_fs-cramfs.conf
如果您选择 yes,则 modprobe
命令会调用一个脚本,用于创建从所提供文件系统的配置文件指向 /dev/null
的符号链接。因此,会从阻止列表中去除该文件系统。
1.11 Linux 中的大型文件支持 #
最初,Linux 支持的最大文件大小为 2 GiB(231 字节)。除非文件系统支持大型文件,否则 32 位系统上的最大文件大小为 2 GiB。
目前,我们的所有标准文件系统都具有 LFS(large file support,大型文件支持)功能,理论上可以支持最大为 263 字节的文件大小。表 1.2 “文件和文件系统的最大大小(磁盘格式,4 KiB 块大小)”概述了 Linux 文件和文件系统的当前磁盘上格式的限制。表中的数字基于文件系统使用 4 KiB 块大小的假设得出,这是通用的标准。使用不同的块大小,结果也就不同。使用较稀疏的块时,表 1.2 “文件和文件系统的最大大小(磁盘格式,4 KiB 块大小)”中的最大文件大小可能会大于文件系统的实际大小。
在本文档中:1024 字节 = 1 KiB;1024 KiB = 1 MiB;1024 MiB = 1 GiB;1024 GiB = 1 TiB;1024 TiB = 1 PiB;1024 PiB = 1 EiB(另请参见 NIST: Prefixes for Binary Multiples)。
文件系统(4 KiB 块大小) |
最大文件系统大小 |
最大文件大小 |
---|---|---|
Btrfs |
16 EiB |
16 EiB |
Ext3 |
16 TiB |
2 TiB |
Ext4 |
1 EiB |
16 TiB |
OCFS2(高可用性扩展中可使用的群集感知文件系统) |
16 TiB |
1 EiB |
XFS |
16 EiB |
8 EiB |
NFSv2(客户端) |
8 EiB |
2 GiB |
NFSv3/NFSv4(客户端) |
8 EiB |
8 EiB |
表 1.2 “文件和文件系统的最大大小(磁盘格式,4 KiB 块大小)”介绍了有关磁盘上格式的限制。Linux 内核自身的大小限制同样适用于其处理的文件和文件系统大小。下面介绍了这些限制:
- 文件大小
在 32 位系统上,文件不能超过 2 TiB(241 字节)。
- 文件系统大小
文件系统最大可以为 273 个字节。但是,目前可用的硬件尚不会超出这一限制。
1.12 Linux 内核存储的限制 #
表 1.3 “存储限制” 总结了与 SUSE Linux Enterprise Server 相关联的存储的内核限制。
存储功能 |
限制 |
---|---|
支持的 LUN 最大数量 |
每个目标 16384 个 LUN。 |
每一个单独 LUN 的最大路径数量 |
默认情况下没有限制。每个路径视作一个常规 LUN。 每个目标的 LUN 数量以及每个 HBA 的目标数量决定了实际的限制(光纤通道 HBA 为 16777215)。 |
HBA 的最大数量 |
不限.实际限制取决于系统的 PCI 槽的数量。 |
每个操作系统使用 device-mapper-multipath 的最大路径数量(总计) |
大约为 1024。实际数量取决于每个多路径设备的设备号字符串长度。它是 multipath-tools 中的一个编译时间变量,如果此限制会导致问题,则可提高其值。 |
每一个块设备的最大大小 |
最多 8 EiB。 |
1.13 释放未使用的文件系统块 #
在固态硬盘 (SSD) 和精简配置的卷中,释放未被文件系统使用的块会很有用。在支持 unmap
和 TRIM
操作的所有文件系统上,SUSE Linux Enterprise Server 完全支持执行这种操作。
有两种常用的 TRIM 操作 — 联机 TRIM
和定期 TRIM
。释放设备的最合适方法取决于您的用例。一般情况下,建议使用定期 TRIM,尤其是当设备具有足够的可用块时。如果设备经常接近容量耗尽状态,则最好使用联机 TRIM。
TRIM
操作的支持
在尝试使用 TRIM
操作之前,请始终校验您的设备是否支持该操作。否则,您可能会丢失该设备上的数据。要校验是否支持 TRIM
操作,请运行以下命令:
>
sudo
lsblk --discard
该命令会输出有关所有可用块设备的信息。如果 DISC-GRAN
和 DISC-MAX
列的值不为零,则表示设备支持 TRIM
操作。
1.13.1 定期 TRIM #
定期 TRIM 由 systemd
定期调用的 fstrim
命令进行处理。您也可以手动运行该命令。
要安排定期 TRIM,请如下所示启用 fstrim.timer
:
>
sudo
systemctl enable fstrim.timer
systemd
会在 /usr/lib/systemd/system
中创建一个单元文件。默认情况下,该服务每周运行一次,这种频率通常已足够。但是,您可以通过将 OnCalendar
选项配置为所需值来更改频率。
fstrim
的默认行为是丢弃文件系统中的所有块。您可以在调用该命令时使用选项来修改此行为。例如,可以传递 offset
选项来定义释放过程的起始位置。有关详细信息,请参见man fstrim
。
fstrim
命令可对存储在 /etc/fstab
文件中且支持 TRIM
操作的所有设备执行修剪 — 为此,请在调用该命令时使用 -A
选项。
要禁用特定设备的修剪,请如下所示将选项 X-fstrim.notrim
添加到 /etc/fstab
文件中:
UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74 / btrfs defaults,X-fstrim.notrim 0 0
1.13.2 联机 TRIM #
每次向设备写入数据时,都会对该设备执行联机 TRIM。
要启用设备的联机 TRIM,请如下所示将 discard
选项添加到 /etc/fstab
文件中:
UID=83df497d-bd6d-48a3-9275-37c0e3c8dc74 / btrfs defaults,discard
或者,在 Ext4 文件系统上,可以使用 tune2fs
命令在 /etc/fstab
中设置 discard
选项:
>
sudo
tune2fs -o discard DEVICE
如果设备是通过 mount
搭配 discard
选项挂载的,还需将 discard
选项添加到 /etc/fstab
:
>
sudo
mount -o discard DEVICE
使用 discard
选项可能会缩短某些低质量 SSD 设备的使用寿命。联机 TRIM 还可能会影响设备的性能,例如,在删除大量数据的情况下。在这种情况下,可能会重新分配一个擦除块,并在短时间后,再次将同一擦除块标记为未使用。
1.14 文件系统查错 #
本节说明文件系统的一些已知问题和可能的解决方案。
1.14.1 Btrfs 错误:设备上没有剩余空间 #
使用 Btrfs 文件系统的根 (/
) 分区停止接受数据。您收到错误“No space left
on device
”。
请参见下列各部分,了解有关此问题的可能原因和预防措施的信息。
1.14.1.1 Snapper 快照使用的磁盘空间 #
如果 Snapper 是针对 Btrfs 文件系统运行的,则“No
space left on device
”问题通常是由于系统上做为快照存储的数据过多所致。
您可以从 Snapper 中去除一些快照,不过,快照不会立即删除,可能不能释放您需要的空间容量。
若要从快照程序中删除文件:
打开终端。
在命令提示符处,输入
btrfs filesystem show
,例如:>
sudo
btrfs filesystem show Label: none uuid: 40123456-cb2c-4678-8b3d-d014d1c78c78 Total devices 1 FS bytes used 20.00GB devid 1 size 20.00GB used 20.00GB path /dev/sda3输入
>
sudo
btrfs fi balance start MOUNTPOINT -dusage=5此命令会尝试将数据重新放置在空的或接近空的数据块中,从而允许收回空间并将其重新指派给元数据。此操作可能需要一些时间(1 TB 数据可能需要很多小时),不过,在此期间系统仍可以使用。
列出快照程序中的快照。输入
>
sudo
snapper -c root list从 Snapper 中删除一或多个快照。输入
>
sudo
snapper -c root delete SNAPSHOT_NUMBER(S)务必先删除最旧的快照。快照生成的时间越长,其占用的空间就越大。
为了避免此问题发生,您可以更改 Snapper 清理算法。有关详细信息,请参见 第 10.6.1.2 节 “清理算法”。控制快照清理的配置值为 EMPTY_*
、NUMBER_*
和 TIMELINE_*
。
如果在文件系统磁盘上搭配使用快照程序和 Btrfs,建议您保留两倍于标准存储建议的磁盘空间容量。YaST 分区程序会自动在 Btrfs 存储建议中为根文件系统建议标准磁盘空间的两倍容量。
1.14.1.2 日志、崩溃和缓存文件使用的磁盘空间 #
如果系统磁盘填满了数据,您可以尝试从 /var/log
、/var/crash
、/var/lib/systemd/coredump
和 /var/cache
中删除文件。
Btrfs root
文件系统子卷 /var/log
、/var/crash
和 /var/cache
在正常运作情况下可能会使用所有可用的磁盘空间,这会导致系统出现故障。为避免出现此状况,SUSE Linux Enterprise Server 提供了 Btrfs 子卷配额支持。有关详细信息,请参见 第 1.2.5 节 “Btrfs 子卷配额支持”。
在测试和开发计算机上,尤其是当应用程序频繁崩溃时,您可能还想查看 /var/lib/systemd/coredump
,内核转储就存储在其中。
1.14.2 Btrfs:跨设备平衡数据 #
btrfs balance
命令是 btrfs-progs 软件包的一部分。它可以在以下示例情况下平衡 Btrfs 文件系统上的块组:
假设您有一个 1 TB 驱动器,其中的 600 GB 被数据使用,然后又添加了另一个 1 TB 驱动器。理论上,平衡后将导致每个驱动器上各有 300 GB 的已用空间。
您的设备上有大量接近空的区块。在执行平衡清除这些区块之前,它们的空间都将不可用。
您需要根据其使用百分比压缩半空的块组。以下命令将平衡使用率等于或小于 5% 的块组:
>
sudo
btrfs balance start -dusage=5 /提示/usr/lib/systemd/system/btrfs-balance.timer
计时器负责每月清理未使用的块组。您需要清除块设备的未满部分,更均匀地分布数据。
您需要在不同的 RAID 类型之间迁移数据。例如,要将一组磁盘上的数据从 RAID1 转换到 RAID5,请运行以下命令:
>
sudo
btrfs balance start -dprofiles=raid1,convert=raid5 /
要微调 Btrfs 文件系统上平衡数据的默认行为(例如,平衡的频率或挂载点),请检查并自定义 /etc/sysconfig/btrfsmaintenance
。相关选项以 BTRFS_BALANCE_
开头。
有关 btrfs balance
命令用法的细节,请参见其手册页 (man 8 btrfs-balance
)。
1.14.3 不要在 SSD 中进行碎片整理 #
Linux 文件系统包含相应的机制用于避免数据碎片,因此通常没有必要执行碎片整理。但在某些使用场合下,数据碎片不可避免,而对硬盘进行碎片整理可以明显提高性能。
这种做法仅适用于传统的硬盘。在使用闪存存储数据的固态硬盘 (SSD) 中,固件提供的算法可以确定要将数据写入哪些芯片。数据通常分散在设备的各个位置。因此,对 SSD 进行碎片整理并不能获得所需的效果,反而会因为写入不必要的数据而缩短 SSD 的寿命。
出于上述原因,SUSE 肯定地建议不要对 SSD 进行碎片整理。某些供应商还会警告对其固态硬盘进行碎片整理所产生的后果。这些品牌包括但不限于:
HPE 3PAR StoreServ All-Flash
HPE 3PAR StoreServ Converged Flash
1.15 更多信息 #
上面介绍的每个文件系统项目都有自己的主页,可以在其中找到邮件列表信息、更多文档和常见问题:
Kernel.org 上的 Btrfs Wiki:https://btrfs.wiki.kernel.org/
E2fsprogs: Ext2/3/4 File System Utilities: http://e2fsprogs.sourceforge.net/
OCFS2 Project(OCFS2 项目):https://oss.oracle.com/projects/ocfs2/
Wikipedia 项目上的“Comparison of File Systems”(文件系统比较,网址:http://en.wikipedia.org/wiki/Comparison_of_file_systems#Comparison)中提供了对各种文件系统(不仅仅是 Linux 文件系统)更深入的比较。