UFS——Unix File System是BSD4.4附带的文件系统的直系后代。
UFS作为原始FreeBSD文件系统的地位让它在整个操作系统中成长,许多UFS概念是其他文件系统的基础。必须了解UFS的基础知识,才能理解FreeBSD是如何管理文件系统的。
当前使用的是UFS的第二个版本,即UFS2。
FreeBSD支持两种主要的文件系统:UFS和ZFS。
ZFS的所有功能都会带来性能成本,ZFS需要大量内存和更多的CPU时间。
Netflix的FreeBSD系统选择使用UFS向客户提供视频。
在高负载、高容量的数据库系统上,应尝试UFS和ZFS,看看哪种更适合。
不建议在32位硬件上使用ZFS文件系统。
不建议在内存小于4GB的系统上使用ZFS;绝对不要在内存小于2GB的系统上使用ZFS。
在嵌入式和小型系统中,UFS比ZFS更适合。
在虚拟机中,特别是基于磁盘映像的虚拟机中,ZFS的特性将不再适合。比如在KVM进行虚拟化并为FreeBSD提供磁盘映像,但从磁盘映像的副本进行恢复会很困难。ZFS更适合在真实的硬件上运行。
ZFS是卷管理器和文件系统的组合。
UFS并不完美。修复损坏的文件系统需要时间和系统内存。粗略的说,fsck需要大约700MB内存来处理一个1TB的文件系统。
大多数计算机系统都有相当比例的内存和存储系统,随着存储系统的增长,可能没有足够的内存来修复它。
评估环境、运行测试,最终做出选择。
我们所说的UFS由两个部件组成:Unix文件系统和快速文件系统(FastFileSystem——FFS)。
UFS处理文件名、将文件放入目录、权限以及所有面向用户的事情。 FFS负责将文件写入磁盘并对其进行快速访问。
FFS有超级块(superblocks)、块(blocks)、和索引节点(inodes)组成。
其他文件系统也使用块、片段和某种类型的索引节点。然而,每个文件系统使用的索引系统在很大程度上是唯一的,并且是定义文件系统性能和特征的重要组成部分。
理论上,可以在与FFS不同的存储层上运行UFS,从而可以尝试基于日志或范围的策略。
vnode是FreeBSD的一个存储抽象层。它是内核和用户正在使用的任何特定文件系统之间的转换层。
当你将文件写入UFS文件系统时,内核会将数据寻址到vnode,而vnode又映射到UFS索引节点和块。当您写入FAT32文件系统时,内核会将数据寻址到映射到FAT32文件系统特定部分的vnode。
使用-o和选项来指定挂载方式,例如以下命令以只读(read-only)方式挂载/usr/local:
xxxxxxxxxx
# mount –o ro /usr/local
也可以在/etc/fstab中指定挂载选项。例如以下行与以上示例效果相同:
xxxxxxxxxx
/dev/gpt/usrlocal /usr/local ufs ro 2 2
接下来的章节介绍常用的选项,特别排除了通用FreeBSD内核不支持的挂载选项。
如果仅想查看文件系统中的内容,而不允许修改它们,可以用只读方式挂载它。
在大多数情况下,这是挂载文件系统最安全、最无用的方法。
过度的只读挂载(比如管理员的根分区/root,或/usr)会使系统维护复杂化。
只读挂载在损坏的计算机上特别有价值。FreeBSD不允许以读写方式挂载损坏或脏的文件系统,只允许以只读方式挂载它们。只读挂载使管理员有机会从即将耗尽的磁盘中恢复数据。
使用ro或rdonly选项只读挂载文件系统。
同步(或sync)挂载是文件系统最安全的挂载方式。安全得有些愚蠢。当程序将数据写入同步挂载的磁盘时,内核会等待验证写入是否成功完成,然后再通知程序写入已完成。
使用sync选项同步挂载文件系统。
软更新在很大程度上取代了异步(asynchronous)挂载,但FreeBSD仍支持它们。
当程序将数据写入异步挂载的文件系统时,内核会向程序报告写入成功,而无需等待磁盘确认它确实向磁盘写入了任何内容。
如果系统有问题,比如停电,很有可能会丢失数据或损坏文件系统。
async非常适合用于临时文件系统,比如内存文件系统,关机时会消失。
使用async选项异步挂载文件系统。
FreeBSD默认使用称为noasync的同步和异步挂载方式。
当写入异步挂载的文件系统时,影响数据的索引点时同步写入的,实际文件时异步写入的。结合软更新,noasnyc挂载创建了一个非常耐损坏或损坏的文件系统。
除非指定其他选项,否则默认情况下进行noasync挂载。
UFS会记录文件的最后一次访问时间。如果不需要这些数据,可以以noatime方式挂载磁盘,这样UFS在用户查看文件时就不会更新时间戳。
建议在虚拟机、闪存介质或负载繁重的磁盘上使用noatime选项。
在/etc/fstab中指定此选项告诉系统在启动时不自动挂载此文件系统。
最常见的方法是为CD驱动器创建挂载点,以避免开机时停在等待插入CD的状态。
UFS试图对物理介质上的读写进行集群,以优化性能。
与其将文件分散在硬盘上,不如将整个文件写成更大的块。
noclusterr选项禁用读集群;noclusterw选项禁用写集群。
noexec选项阻止内核执行磁盘上的任何程序。
noexec不会阻止用户在Perl、Python等语言中运行shell脚本或解释脚本。因为解释器通常不在noexec分区上。
对于用于不同操作系统或硬件架构的磁盘,建议使用noexec挂载,以防止误操作运行其上的程序。
nosuid选项禁用文件系统上的setuid文件。
setuid程序允许用户以其他用户的身份运行程序。
禁用符号链接或文件的备用名称(alternate name)。
禁用符号链接可确保看起来位于文件系统上的所有文件实际上都是该文件系统的本地文件。
UFS会根据文件系统的满度改变其行为。
在空文件系统上,它会优化自己的速度。一旦文件系统开始填满,它会切换以优化空间利用率。
UFS保留了8%的文件系统空间用于动态优化。
由于保留了这些空间,分区可以显示为超过100%已满。
8%的保留空间对于普通文件系统来说问题不大,但对于非常大的文件系统来说就相当大了。
文件系统满92%以上(占可见大小总数的85%和8%的保留)会自动从时间优化切换到空间优化。它会对一些文件进行碎片化,以更有效地利用空间。
分割文件会降低性能。
随着自由空间的缩小,UFS越来越努力提高其空间利用率。
一个满的UFS文件系统的运行速度大约是一个不太满的文件系统的三分之一。
使用funefs命令可以调整文件系统上保留的磁盘空间量,但效果不会太好。
增加保留空间百分比并不能提高性能。且更容易使文件系统变满,普通用户将无法写入新文件。
保留的而空间可能会混淆NFS等第三方工具。其他一些挂载UFS分区的操作系统会看到分区已满,并告诉他们无法写入磁盘,尽管本地客户端可以写入。故障排除时需要注意这一现象。
FreeBSD提供了几种方法来提高UFS文件系统的弹性,包括UFS和GEOM基本的软更新和日志记录。根据实际需求选择一种弹性方法。
普通UFS没有任何额外的弹性,非常可靠。UFS通过仔细地完整性检查来实现这种弹性,特别是在停电等意外停机后。
弹性的重点不是验证磁盘上的数据。现代磁盘的大小意味着在没有额外弹性的情况下,验证可能需要很长时间。
当数据临时缓存在驱动器上的存储芯片中时,某些旧型号的消费级磁盘驱动器会向操作系统报告数据完全地存储在磁盘上。当电源发生故障时,这种存储芯片应该会保留剩余地电量,刚好足够将最后几个字节写入到磁盘上。各种UFS弹性方案依赖于磁盘在声称有数据时实际向盘片写入数据。此硬盘的写缓存中断了软更新和日志记录。对于这类旧型号的硬盘,强烈建议更换掉。
软更新是一个组织和安排磁盘写入的过程,这样文件系统元数据在任何时候都保持一致,几乎具有异步挂载的性能和同步挂载的可靠性。
软更新并不意味着所有数据总是安全地写入磁盘——在错误的时刻发生电源故障会吃掉数据。
无论操作系统如何操作,在电源断电的精确毫秒内写入磁盘的文件都无法到达磁盘。但磁盘上的实际内容在内部是一致的。软更新是UFS文件系统能够非常快地从故障中恢复。
您可以在卸载文件系统或创建文件系统时启用和禁用软更新。
随着文件系统越来越大,软更新显示了它们的局限性。数TB的文件系统需要相当长的一段时间才能从计划外停机中恢复。原始的软更新日记纸(http://www.mckusick.com/softdep/suj.pdf)提到一个92%满的14个驱动器组成的阵列被不一致的数据故意污染,需要10个小时进行完整性检查。在那之前,你需要一本日记。
日志文件系统记录实际文件系统之外的任何更改。如果系统意外崩溃,文件系统会自动从日志中恢复任何更改。
UFS日志是建立在软更新之上的。软更新日志记录所有元数据更新,而不是记录所有事务,这样文件系统就可以始终恢复到内部一致的状态。这消除了在系统启动时进行文件系统完整性检查的任何需要。
基准测试表明,UFS日志记录比正常软更新需要的时间更少。但却需要更多的I/O开销。因为系统必须记录所有文件系统事务。
恢复时间大大缩短,对于正常软更新需要的10小时,从日志中恢复只需不到一分钟时间。
当使用软更新日志记录时,UFS的快照将不起作用。如果必须通过转储快照进行备份,则不要使用纯软更新。
可以在未挂载的文件系统上,或在创建文件系统时启用或禁用UFS日志记录。
FreeBSD可以使用gjournal在GEOM级别进行日志记录。
gjournal记录文件系统事务。在系统启动时,FreeBSD会检查日志文件中是否有任何尚未写入磁盘的更改,并进行这些更改,以确保文件系统的一致性。
GEOM是独立于文件系统的。GEOM日志不在乎上面的文件系统是UFS还是EXT2FS或其他类型,它只是记录和回放(play back)业务。
gjournal不仅记录元数据,还记录所有文件系统事务。不太可能在系统故障中丢失数据,但所有内容都会写入两次,这会影响性能。
gjournal每个文件系统使用1GB的磁盘,这意味着必须为日志保留足够的空间。可以将日志添加到另一个磁盘,或者在为日志留出空间的情况下将日志包含在分区中。
GEOM日志早于软更新日志。
除非有特殊的理由,否则应使用软更新日志。如果不能使用软更新日志,则应使用软更新。
如果有应用程序与以上两个冲突,才考虑GEOM日志记录。
使用newfs创建UFS文件系统。
使用-j选项创建软更新日志文件系统。使用-U选项创建软更新文件系统。
以下命令在/dev/da0p4上创建一个UFS日志文件系统:
xxxxxxxxxx
# newfs -j /dev/da0p4
/dev/da0p4: 5120.0MB (10485760 sectors) block size 32768, fragment size 4096
using 9 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
super-block backups (for fsck_ffs -b #) at:
192, 1282432, 2564672, 3846912, 5129152, 6411392, 7693632, 8975872, 10258112
Using inode 4 in cg 0 for 33554432 byte journal
newfs: soft updates journaling set
创建过程中会反馈有关新文件系统的一些基本信息,例如其大小、扇区数量以及块和片段的大小。下面的geom信息在现代磁盘上基本上是不相关的,但如果计划有很多小文件,索引节点的数量可能很重要。
在创建文件系统时,newfs会打印出它创建的每个备份超级块的位置。超级块对于恢复损坏的文件系统非常重要。如果主超级块损坏(damaged or corrupted),可以运行fsck使用备用超级块恢复数据。
如果要使用GEOM日志记录,则必须在创建文件系统之前配置日志记录的GEOM提供者。
首先要加载gjournal内核模块,可以手动加载内核模块,在/boot/loader.conf中在启动时加载模块,也可以使用gjournal命令:
xxxxxxxxxx
# gjournal load
现在决定是将日志与文件系统一起存储,还是存储在单独的分区中。
在不同的磁盘上使用单独的日志分区可以提高性能,只要磁盘不竞争吞吐量。
更常见的是,将日志与文件系统一起存储。使用gjournal label命令将分区转换为GEOM日志记录:
xxxxxxxxxx
# gjournal label da0p5
如果有单独的日志设备,请将其作为额外的命令行参数:
xxxxxxxxxx
# gjournal label da0p5 da1p6
如果成功,这些命令将静默运行。它们创建了一个与日志记录设备同名的新设备节点,末尾为.journal。也就是说,如果在da0p5上进行日志,将会得到设备节点/dev/da0p5.journal。在以.log结尾的设备节点上执行所有文件系统操作。
在日志上创建文件系统。使用-J选项告诉UFS它运行在gjournal顶部。不要将软更新日志与GEOM日志结合使用。
GEOM日志文件系统必须异步挂载。通常不建议这么做,因为异步将转储数据直接写入磁盘设备,而不是等待确认数据安全存储在物理介质上。
当使用gjournal时,GEOM会处理通常由文件系统管理的验证和完整性检查。
在/etc/fstab中使用async作为挂载选项:
xxxxxxxxxx
/dev/da0p5.journal /var/log ufs rw,async 2 2
可以将现有的文件系统转换为使用GEOM日志,前提是分区的最后一个扇区没有被文件系统占用,并且有一个单独的日志记录设备。大多数时候,备份数据并重新创建文件系统或使用软更新日志记录更容易。
UFS几乎在所有情况下都有合理、灵活的默认值。可以通过tunefs命令调整UFS以满足特定需求。这种调优的大部分功能都是启用和禁用。此外,还可以调整文件系统写入文件的方式、管理可用空间的方式和标签。
使用tunefs -p查看当前设置:
xxxxxxxxxx
# tunefs -p /usr
tunefs: POSIX.1e ACLs: (-a) disabled
tunefs: NFSv4 ACLs: (-N) disabled
tunefs: MAC multilabel: (-l) disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j) enabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e) 4096
tunefs: average file size: (-f) 16384
tunefs: average number of files in a directory: (-s) 64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k) 6408
tunefs: optimization preference: (-o) time
tunefs: volume label: (-L)
这个文件系统同时使用软更新和软更新日志。它不使用GEOM日志或TRIM。
再往下看,分散在文件系统内部,可以看到最小百分比的可用空间和UFS标签(此处为空白)。
强烈不建议对默认设置进行修改。
如要修改,需要在未挂载的情况下进行,最好是将系统以单用户模式启动,然后修改。
使用-n选项启用或禁用分区上的纯软更新:
xxxxxxxxxx
# tunefs -n enable /usr
tunefs: soft updates set
使用-j选项设置日志软更新:
xxxxxxxxxx
# tunefs -j enable /dev/da0p6
Using inode 4 in cg 0 for 33554432 byte journal
tunefs: soft updates journaling set
要禁用软更和/或日志记录,可在以上命令中使用disable:
xxxxxxxxxx
# tunefs -j disable /usr
Clearing journal flags from inode 4
tunefs: soft updates journaling cleared but soft updates still set.
tunefs: remove .sujournal to reclaim space
禁用软更新日志记录后,删除现有日志。挂载文件系统,并删除文件系统根目录中的.sujournal文件。
UFS保留了每个分区的8%,这样它就有空间重新排列文件,以便更好地访问。
使用-m选项可以修改这个百分比:
xxxxxxxxxx
# tunefs -m 5 /dev/da0p6
tunefs: minimum percentage of free space changes from 8% to 5%
tunefs: should optimize for space with minfree < 8%
现在有了更多的可用空间,但UFS运行速度会变慢,因为它总是尽可能紧密地打包文件系统。
固态硬盘使用磨损均衡(wear leveling)来延长其使用寿命。
当文件系统在块不再使用时通知SSD时,损耗均衡效果最佳。这样做的协议称为TRIM(TRIM并不是首字母缩写,硬件命令通常以大写字母显示)。
使用-t选项在SSD支持的文件系统上启用TRIM支持。
xxxxxxxxxx
# tunefs -t enable /dev/da0p6
tunefs: issue TRIM to the disk set
为了获得最佳效果,应为固态硬盘上每个分区启用TRIM。
使用标签标识文件系统比使用设备节点更好,因为设备节点可以更改。
通常,可以标记文件系统所在的GPT分区,但无法标记MBR分区。UFS文件系统上的标签和分区上的标签一样有效。
使用-L选项标记UFS文件系统:
xxxxxxxxxx
# tunefs -L home /dev/da0p6
UFS标签出现在/dev/ufs目录中。在/etc/fstab中使用此设备条目可以避免设备重命名混乱:
xxxxxxxxxx
/dev/ufs/home /home ufs rw 0 0
GEOM枯竭问题依然存在。
在UFS上读写文件的效率与读写的块和碎片的数量成正比。
FreeBSD选择默认的块和碎片大小,以容纳最广泛的文件。
如果某文件系统主要包含大文件,可以在创建文件系统时考虑增加块大小。
无法更改现有文件系统的块大小。
块大小必须是2的幂。
默认块大小为32K,即32768字节。在newfs命令中使用-b选项指定块的大小。
UFS预计碎片的大小是块的八分之一。更改块大小时,newfs会自动正确设置碎片大小。
可以使用-f选项强制特定的非标准碎片大小,但这会损害性能。应让newfs根据块大小计算碎片大小。
以下命令在创建文件系统时指定64K块。newfs命令自动将碎片大小设置为8K:
xxxxxxxxxx
#newfs -b 64K -L home /dev/da0p6
如果有很多小文件,如果物理存储介质支持,可以考虑使用较小的块大小。
如果文件系统的碎片大小小于底层磁盘的扇区大小,性能会暴跌。
FreeBSD默认为4K碎片。如果磁盘有4K扇区,不要使用更小的块。
在遇到新能问题之前,不要自定义UFS块大小。
使用growfs命令扩展UFS文件系统。此操作最大困难是找到一个放置文件系统的地方。
在虚拟机中扩充UFS文件系统比较便利,但在实体硬件中扩充UFS文件系统比较复杂,建议考虑创建一个新的、更大的分区,并将文件系统移动到该分区。
要扩展文件系统,需要在现有分区旁边有空间。
查看磁盘上的分区,确定要扩展的分区及其两侧的分区。必须删除其中一边的分区以腾出空间来扩展目标分区。 这意味着必须找到一个地方来放置要移动的分区。
默认情况下,growfs会扩展文件系统,直到它填满它所在的分区。:
xxxxxxxxxx
# growfs /dev/ufs/usrlocal
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/ufs/usrlocal from 9.0GB to 15GB? [Yes/No] yes
super-block backups (for fsck_ffs -b #) at:
19233792, 20516032, 21798272, 23080512, 24362752, 25644992, 26927232,
28209472, 29491712, 30773952
需要注意的一点是,当growfs要求确认时,必须输入完整的单词Yes,其他答案都会取消操作。
可以使用-s选项指定大小:
xxxxxxxxxx
# growfs -s20g /dev/ufs/usrlocal
强烈建议使文件系统与底层分区大小相同,以免产生困扰。
停电、硬件故障和系统管理不当都可能会损坏文件系统。UFS的所有弹性技术都是为了保证数据完整性,但没有什么能完美确保数据完整性。
如果内置的完整性管理工具失效,可以尝试以下操作。
当FreeBSD系统关闭时,内核会将其所有数据同步到已挂载的文件系统,将文件系统标记为干净(clean),然后关闭电源。这是由一个名为syncer的内核进程处理的。
如果你看到系统关闭,你会在整理硬盘时看到来自同步器(syncer)的状态信息。
同步器实际上并不遍历硬盘上需要更新的索引节点和块的列表,而是遍历需要同步的vnode的列表。由于软更新(soft update),将一个vnode写入磁盘可能会生成另一个脏vnode。将看到写入磁盘的缓冲区数量从高位迅速下降,然后在系统执行最终写入时在低位之间反弹一两次。
如果同步器未完成其工作,则会得到脏磁盘。
脏(dirty)或不干净(unclean)的文件系统处于中间状态(intermediate state)。
操作系统已要求将信息写入磁盘,但数据尚未完全存储在物理介质上。部分数据块可能已被写入,或者索引节点可能已被编辑,但数据未被写出,或者两者的任意组合。
如果断电或系统在磁盘变脏时死机,文件系统将从中间状态变为不确定状态(indeterminate)。
内核看到它有一个损坏的文件系统,但通常不确定该怎么办。日志文件系统会自动恢复,但如果没有日志,就必须手动清理文件系统。
清理文件系统可以恢复数据完整性,但并不一定意味着所有数据都在磁盘上。
如果系统死机时文件被半写到磁盘,则文件将丢失。无法恢复丢失的文件的一半,而磁盘上的一半基本上也是无用的。
FreeBSD在启动时验证文件系统的清洁度,并拒绝挂载不干净的文件系统。如果所需的文件系统(如/usr)变脏,引导将在单用户模式下停止。
在机器完成启动之前,必须清理文件系统。
可以手动以只读方式挂载脏文件系统,以便从中复制文件,但最常见的时清理文件系统。
通过日志记录或使用fsck清理文件系统。
日志记录的目的是自动清理文件系统。日志记录在磁盘的一个单独部分上对文件系统所做的所有更改。如果系统崩溃,可以从日志中恢复最近的文件系统更改。
如果正在使用UFS日志记录,则日志应快速自动地将脏文件系统恢复到干净状态。
日志几乎总是有效的。
如果在非FreeBSD文件系统上使用GEOM日志记录,它应该恢复它上面的文件系统。
如果GEOM日志失败,就必须使用文件系统的原生工具来修复它。
FreeBSD包括用于修复UFS的fsck。
当重新启动的系统发现一个没有日志的脏UFS文件系统时,它会自动检查该文件系统并尝试清理它。
fsck会验证每个文件是否都附加到正确的索引节点和正确的目录中。如果检查成功,fsck将声明文件系统为干净。
然而,文件系统可能不一致。也许数据块没有附加索引节点,或者索引节点引用空白块。
当自动fsck运行发现这些问题时,它就会停止。
如果在系统启动期间发生这种情况,则启动失败,而进入单用户模式、手动运行fsck的请求和命令提示符。
如果现在运行fsck,fsck将验证磁盘上分配的每个块和索引节点。它会发现任何与索引节点分离的块,并对它们如何组合做出有根据的猜测。它可能无法成功识别这些文件属于哪个目录。
然后,fsck程序会问你一个重要问题:它是否应该为此文件执行这些修复。如果回答n,fsck会删除损坏的文件;如果回答y,则会重新重新组装文件。
fsck对每个问题文件都会问这个问题。如果它无法识别文件所属的目录,它会将找到的文件添加到文件系统根目录中的lost+found目录中,并使用一个数字作为文件名。
如果执行了fsck /usr,就一定要检查 /usr/lost+found目录中是否有放错位置的文件。
必须配合file、more、string、grep等命令手动识别这些文件。
首先用fsck -p整理(preening)文件系统。这会自动对相对无害的问题回答yes,这些问题在正常情况下通常不会导致数据丢失。大多数情况下,这会修复所有问题,但如果失败,它会要求运行完整的fsck。
完整的fsck是一种完整的文件系统完整性检查。它检查每个块、每个索引节点、每个超级块、每件事,并询问是否修复它发现的错误。它会询问每一个错误。每个文件都可能有错误,这意味着可能会一遍又一遍地键入y。
如果要盲目信任fsck的能力,可以运行fsck -y,这将告诉fsck假设你对每个问题都回答yes,即使是真正危险的问题。
运行fsck -y可能会导致问题。有时,当在-current上运行实验性文件系统或做其他愚蠢的事情时,fsck可能会把每个文件系统的全部内容迁移到lost+found中。
在一个使用标准UFS文件系统运行FreeBSD版本的生产系统中,fsck -y可能更安全、更可靠。
可以在/etc/rc.conf中设置fsck_y_enable=YES来告诉服务器在启动时若遇到不干净的文件系统,则运行fsck -y。
许多FreeBSD文档都提到背景fsck。此技术允许FreeBSD在多用户模式下运行的系统上执行文件系统完整性检查。当引导系统发现无法通过日志恢复的脏硬盘,但文件系统损坏看起来相当轻微时,它会启动后台fsck。
FreeBSD在服务器运行时在后台运行fsck,识别松散的文件并在幕后整理它们。
当使用UFS日志时,FreeBSD几乎从不使用后台fsck。要么文件系统通过日志恢复,要么它完全被弄乱了。
后台fsck有两个主要阶段。在引导过程中,FreeBSD会对文件系统进行初步评估,并决定在系统运行时是否可以修复损坏。
如果需要完整的单用户模式fsck,内核会中断引导并提示采取行动。 如果损坏很小,并且可以在系统运行期间修复,则它会在后台以低优先级运行修复。
fsck的过程的结果显示在/var/log/messages中。
后台fsck会影响磁盘性能。fsck消耗大部分可用磁盘活动。虽然系统运行缓慢,但至少它可以启动。
在后台fsck检查/var/log/messages是否有错误。如果初步评估错误,分区可能需要全面的fsck。如果该警告出现在日志文件中,请在几小时内安排停机时间以纠正问题。虽然不方便,但计划内停机总好过计划外停机。
挂载脏文件系统肯定会破坏文件系统和内核中的数据。
以读写方式挂载脏文件系统可能会使系统死机,可能会破坏分区上素有剩余数据,粉碎底层文件系统,或将垃圾写入其他文件系统。
不要使用mount命令的-w(写)和-f(强制)选项。
FreeBSD使用以下条件来决定是否以及如何在启动时修复UFS文件系统:
经验论,恢复脏文件系统最安全、最快的方法是使用UFS日志记录。
快照是文件系统在特定时刻的映像。
可以对文件系统进行快照、擦除和更改一些文件,然后从快照中复制未更改的文件。
dump等工具使用快照来确保创建一致的备份。
UFS快照没有ZFS快照强大或灵活,但在其限制范围内,它们是一种可靠的工具。
UFS快照仅在启用了软更新的分区上工作。
每个文件系统最多可以有20个快照。
虽然许多文件系统要求快照位于特定位置,或对用户隐藏快照。但UFS快照仍然是文件。几乎可以将这些文件放在文件系统的任何位置。
传统上,快照位于文件系统根目录的.snap目录中。如果使用的是自动创建快照的工具(如dump),请检查那里的快照文件。建议不要改变快照文件存放的位置,以免后续维护时造成困扰。
使用mksnap_ffs命令创建快照。该程序假设相对当前正在使用的文件系统进行快照。
xxxxxxxxxx
# cd /tmp/
# mksnap_ffs /tmp/.snap/tmp-2014-08-05:1547
快照使用磁盘空间,不能对已满的文件系统创建快照。
快照是文件。它们看起来和其他文件一样。可以把文件放在任何地方。使用find -flags可以查找快照存放的位置:
xxxxxxxxxx
# find /tmp/ -flags snapshot
/tmp/.snap/usr-2014-08-05:1549
/tmp/.snap/tmp-2014-08-05:1547
可以通过将快照作为内存设备挂载来获取访问权限。
以下示例使用mdconfig命令创建一个内存设备,并将快照附加到该内存设备中:
xxxxxxxxxx
# mdconfig -a -t vnode -o readonly -f tmp-2014-08-05:1547
md0
然后把这个内存设备以只读方式挂载到/mnt目录:
xxxxxxxxxx
# mount –r /dev/md0 /mnt
此时/mnt中将包含/tmp在拍快照时包含的文件。
要关闭快照,需要先卸载快照,然后销毁内存设备:
xxxxxxxxxx
# umount /mnt/
# mdconfig -d -u 0
现在用于挂载快照的资源被释放了,快照本身仍然在它原来的位置。
直接删除快照文件可以删除快照:
xxxxxxxxxx
# rm /tmp/.snap/tmp-2014-08-05:1547
快照会占用磁盘空间。
严格来说,快照记录了当前文件系统和拍摄快照时存在的文件系统之间的差异。拍摄快照后,每次文件系统更改都会增加快照的大小。如果删除文件,快照将保留该文件的副本,以便以后恢复。如果您的文件系统变化很快,快照也会增长得很快。
这意味着使用快照清理文件系统变得棘手。如果您的/home分区几乎已满,并且您有它的快照,则从主目录中删除文件不会释放空间。这些文件将添加到快照中。当包含快照的文件系统填满时,FreeBSD可能会死机。
确保带有快照的文件系统始终有足够的可用空间。
如果您尝试拍摄快照,但系统抱怨由于空间不足而无法拍摄,则可能是因为您已经拥有该文件系统的20个快照。请删除快照,然后重试。