test

系统管理指南：设备和文件系统

第 22 章 检查 UFS 文件系统一致性（任务）

本章提供有关检查 UFS 文件系统一致性的概述信息和逐步说明。

以下是本章中的逐步说明列表。

以下是本章中概述信息的列表。

有关 Solaris 10 6/06 发行版中 fsck 的新信息，请参见UFS 文件系统实用程序（fsck、mkfs 和 newfs）的增强功能。

有关 fsck 错误消息的信息，请参见《系统管理指南：高级管理》中的第 28  章 “解决 UFS 文件系统不一致问题（任务）”。

有关本章中引用的 UFS 文件系统结构的背景信息，请参见第 23 章，UFS 文件系统（参考）。

文件系统一致性

UFS 文件系统依赖于一组内部表来跟踪已用的 inode 和可用的块。当这些内部表与磁盘上的数据未正确同步时，会导致不一致性问题，从而需要修复文件系统。

由于以下情况导致操作系统突然终止，文件系统可能会不一致：

文件系统不一致性问题尽管严重，但并不常见。引导系统时，会自动执行对文件系统一致性的检查（使用 fsck 命令）。通常，此文件系统检查会修复它遇到的问题。

fsck 命令将已分配但未引用的文件和目录放置在 lost+found 目录中。将 inode 编号指定为未引用的文件和目录的名称。如果 lost+found 目录不存在，则 fsck 命令将创建它。如果 lost+found 目录中没有足够的空间，则 fsck 命令会增加其大小。

有关 inode 的说明，请参见Inode。

如何记录文件系统的状态

fsck 命令使用存储在超级块中的状态标志来记录文件系统的状态。fsck 命令使用此标志来确定是否需要检查文件系统的一致性。/sbin/rcS 脚本在引导期间会使用此标志，此外 fsck -m 命令也会使用此标志。如果忽略 fsck -m 命令的结果，则可以检查所有文件系统，无论状态标志是何设置。

有关超级块的说明，请参见超级块。

下表给出了可能的状态标志值。

表 22–1 文件系统状态标志的值

状态标志值 

说明 

FSACTIVE

指示已挂载的文件系统在内存中具有已修改的数据。如果已挂载文件系统具有此状态标志，则表明当系统断电时，用户数据或元数据将会丢失。 

FSBAD

指示文件系统包含不一致的文件系统数据。 

FSCLEAN

指示未损坏的、干净取消挂载的文件系统。 

FSLOG

指示文件系统已启用日志记录功能。设置了此标志的文件系统要么已挂载，要么已取消挂载。如果文件系统已启用日志记录功能，则只能具有标志 FSLOG 或 FSBAD。禁用日志记录功能的文件系统可以具有 FSACTIVE、FSSTABLE 或 FSCLEAN 标志。

FSSTABLE

指示空闲的已挂载文件系统。如果已挂载文件系统具有此状态标志，则表明当系统断电时，用户数据或元数据都不会丢失。 

fsck 命令检查和尝试修复的内容

本节介绍文件系统正常运行时发生的情况、可能会出现的问题、fsck 命令（检查和修复实用程序）可查找的问题，以及此命令如何更正它找到的不一致性问题。

为什么可能出现 UFS 文件系统的不一致性问题

在每个工作日中，可能会创建、修改和删除数百个文件。每次修改文件时，操作系统都会执行一系列文件系统更新。如果这些更新被可靠地写入磁盘，便会产生一致的文件系统。

用户程序执行更改文件系统的操作（例如写入操作）时，会先将要写入的数据复制到内核中的核心缓冲区。通常，以异步方式处理磁盘更新。尽管在写入系统调用返回很长时间之后才会写入数据，但是允许用户进程继续执行。这样，在任何给定时间，由于文件系统驻留在磁盘上，因此它将滞后于核心信息所表示的文件系统状态。

当缓冲区需要用于其他用途时，或者内核自动运行 fsflush 守护进程（时间间隔为 30 秒）时，将更新磁盘信息以反映核心信息。 如果在未写出核心信息的情况下停止系统，则磁盘上的文件系统可能会处于不一致状态。

文件系统可能由于以下几种原因出现不一致性问题。最常见的原因是操作错误和硬件故障。

异常关机可能会导致此类问题，例如未正确关闭系统，或者未采用正确的方式使已挂载的文件系统脱机。为防止异常关机，在关闭系统、从驱动器中物理移除磁盘组或使磁盘脱机之前，必须将文件系统的当前状态写入磁盘（即“进行同步”）。

不一致性问题也可能是由硬件缺陷或者磁盘或控制器固件的问题导致的。在磁盘驱动器上，块随时都可能会损坏。此外，磁盘控制器可能无法正常工作。

接受一致性检查的 UFS 组件

本节介绍 fsck 命令将针对以下 UFS 文件系统组件执行的各种一致性检查：超级块、柱面组块、inode、间接块和数据块。

有关 UFS 文件系统结构的信息，请参见UFS 文件系统的柱面组结构。

超级块检查

超级块存储摘要信息，它是 UFS 文件系统中最常损坏的组件。对文件系统 inode 或数据块进行的每个更改也会修改超级块。如果 CPU 暂停工作且最后一个命令不是 sync 命令，则几乎可以肯定超级块会被损坏。

将根据以下内容检查超级块是否存在不一致性问题：

文件系统大小和 Inode 列表大小检查

文件系统大小必须大于超级块和 inode 列表所用的块数。inode 数必须小于文件系统所允许的最大数。一个 inode 表示一个文件的所有信息。对于 fsck 命令，文件系统大小和布局信息是最关键的信息。无法实际检查这些大小，因为它们是在创建文件系统时静态确定的。但是，fsck 命令可以检查这些大小是否在合理的范围内。所有其他文件系统检查都要求这些大小正确。如果 fsck 命令检测到主超级块的静态参数已损坏，则会要求操作员指定备用超级块的位置。

有关 UFS 文件系统结构的更多信息，请参见UFS 文件系统的柱面组结构。

空闲块检查

空闲块存储在柱面组块图中。fsck 命令检查标记为空闲的所有块是否未被任何文件请求。将所有块统计在内后，fsck 命令将检查空闲块数与 inode 所请求的块数之和是否等于文件系统中的总块数。如果块图出现任何错误，则 fsck 命令将重新构建它们，不考虑已分配的块。

超级块中的摘要信息包括文件系统中空闲块总数的计数。fsck 命令将此计数与它在文件系统中找到的空闲块数进行比较。如果这两个计数不一致，则 fsck 命令会将超级块中的计数替换为实际的空闲块计数。

空闲 Inode 检查

超级块中的摘要信息包含文件系统中空闲 inode 的计数。fsck 命令将此计数与它在文件系统中找到的空闲 inode 数进行比较。如果这两个计数不一致，则 fsck 命令会将超级块中的计数替换为实际的空闲 inode 计数。

Inode

将按顺序从 inode 2 开始检查 inode 列表（Inode 0 和 inode 1 是保留的）。将根据以下内容检查每个 inode 是否存在不一致性问题：

Inode 的格式和类型

每个 inode 都包含模式字，用于说明 inode 的类型和状态。Inode 可以是以下九种类型之一：

Inode 可能处于以下三种状态之一：

创建文件系统时，会保留固定数目的 inode。但是，仅在需要这些 inode 时才分配它们。已分配 inode 是指向文件的 inode。未分配 inode 不指向文件，因此它应该为空。部分分配状态表示 inode 未正确格式化。例如，如果因硬件故障而将错误数据写入 inode 列表，则 inode 将变为此状态。fsck 命令可以执行的唯一更正操作是清除 inode。

链接计数检查

每个 inode 都包含与其链接的目录项数的计数。fsck 命令通过从根 (/) 目录开始检查整个目录结构并计算每个 inode 的实际链接计数，验证每个 inode 的链接计数。

存储在 inode 中的链接计数和由 fsck 命令确定的实际链接计数之间的差异可能是以下三种类型之一：

重复块检查

每个 inode 都包含由 inode 请求的所有块的列表或指向列表的指针（间接块）。由于间接块由 inode 拥有，因此间接块的不一致性问题会直接影响拥有间接块的 inode。

fsck 命令将 inode 请求的每个块编号与已分配块的列表进行比较。如果另一个 inode 已请求某个块编号，则将该块编号放置在重复块列表中。否则，会将已分配块的列表更新为包括该块编号。

如果发现重复块，则 fsck 命令再次遍历 inode 列表，以查找请求每个重复块的其他 inode。fsck 命令不能肯定哪个 inode 出现错误。因此，fsck 命令会提示您选择应保留和应清除的 inode。请注意，inode 中的大量重复块可能是由于未将间接块写入文件系统而导致的。

坏块编号检查

fsck 命令检查 inode 请求的每个块编号，以确定其值是否大于文件系统中第一个数据块的值并小于最后一个数据块的值。如果块编号超出了此范围，则认为它是坏块编号。

inode 中的坏块编号可能是由于未将间接块写入文件系统而导致的。fsck 命令会提示您清除 inode。

Inode 大小检查

每个 inode 都包含它所引用的数据块数的计数。实际数据块的数目等于已分配数据块与间接块的和。fsck 命令计算数据块数，并将该块计数与 inode 请求的块数进行比较。如果 inode 包含的计数不正确，则 fsck 命令会提示您修复它。

每个 inode 都包含一个 64 位大小的字段。此字段说明与 inode 关联的文件中的字符数（数据字节）。粗略检查 inode 的大小字段是否一致时，会使用大小字段中所示的字符数，以计算应与 inode 关联的块数，然后将该块数与 inode 请求的实际块数进行比较。

间接块

间接块由 inode 拥有。因此，间接块的不一致性问题会影响拥有它的 inode。可以检查的不一致性问题如下：

对直接块也执行以上列出的一致性检查。

数据块

inode 可以直接或间接引用三种数据块。引用的所有块必须属于同一种类。这三种类型的数据块如下：

纯文本数据块包含存储在文件中的信息。符号链接数据块包含存储在符号链接中的路径名。目录数据块包含目录项。fsck 命令只能检查目录数据块的有效性。

通过 inode 的 mode 字段中的项，可以将目录与常规文件区分开。与目录关联的数据块包含目录项。检查目录数据块是否存在一致性问题涉及以下内容：

未分配目录检查

如果目录数据块中的 inode 编号指向未分配的 inode，则 fsck 命令删除该目录项。如果修改并写出包含新目录项的数据块，但未写出 inode，则可能出现此情况。如果突然关闭 CPU，则可能出现此情况。

错误 Inode 编号检查

如果目录项 inode 编号超出了 inode 列表的范围，则 fsck 命令删除该目录项。将错误数据写入目录数据块时，可能出现此情况。

错误 “.” 和 “..” 项检查

“.” 的目录 inode 编号项必须是目录数据块中的第一项。目录 inode 编号必须引用自身。即，其值必须等于目录数据块的 inode 编号。

“..” 的目录 inode 编号项必须是目录数据块中的第二项。目录的 inode 编号值必须等于父目录的 inode 编号或它自己的 inode 编号（如果该目录是根 (/) 目录）。

如果 “.” 和 “..” 的目录 inode 编号不正确，则 fsck 命令将它们替换为正确值。如果有多个硬链接指向一个目录，则将找到的第一个硬链接视为 “..” 应指向的实际父级。在这种情况下，fsck 命令建议您删除其他名称。

断开的目录

fsck 命令检查文件系统的常规连通性。如果找到未链接到文件系统的目录，则 fsck 命令将该目录链接到文件系统的 lost+found 目录。当 inode 已写入文件系统，但是对应的目录数据块未写入时，可能出现此情况。

常规数据块

与常规文件关联的数据块包含文件的内容。fsck 命令不会尝试检查常规文件的数据块内容的有效性。

fsck 摘要消息

以交互方式运行 fsck 命令且成功完成时，将显示与以下内容类似的消息：


# fsck /dev/rdsk/c0t0d0s7

** /dev/rdsk/c0t0d0s7

** Last Mounted on /export/home

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3 - Check Connectivity

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cyl groups

2 files, 9 used, 2833540 free (20 frags, 354190 blocks, 0.0% fragmentation)

# 

# fsck /dev/rdsk/c0t0d0s7

** /dev/rdsk/c0t0d0s7

** Last Mounted on /export/home

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3a - Check Connectivity

** Phase 3b - Verify Shadows/ACLs

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cylinder Groups 

2 files, 9 used, 2833540 free (20 frags, 354190 blocks, 0.0% fragmentation)

#

fsck 输出的最后一行说明有关文件系统的以下信息：

# files

正在使用的 inode 数

# used

正在使用的段数

# free

未使用的段数

# frags

未使用的非块段数

# blocks

未使用的完整块数

% fragmentation

段百分比，其中：空闲段数 x 100/文件系统中的总段数

有关段的信息，请参见段大小。

以交互方式检查和修复 UFS 文件系统

在以下情况下可能需要以交互方式检查文件系统：

正在使用的文件系统出现不一致性问题时，可能会在控制台窗口或系统消息文件中显示错误消息。或者，系统可能会崩溃。例如，系统消息文件 /var/adm/messages 可能包括与以下内容类似的消息：


Sep  5 13:42:40 hostname ufs: [ID 879645 kern.notice] NOTICE: /: unexpected

free inode 630916, run fsck(1M)

hostname 是报告该错误的系统。

使用 fsck 命令之前，您可能希望参阅以下内容以了解有关解决 fsck 错误消息的信息：

运行 fsck 命令检查 UFS 文件系统时，请牢记以下要点：

Procedure如何从备用引导设备检查根 (/)、/usr 或 /var 文件系统

有关 Solaris 10 6/06 发行版中 fsck 的新信息，请参见UFS 文件系统实用程序（fsck、mkfs 和 newfs）的增强功能。如果看到以下消息，则无需重新运行 fsck：


***** FILE SYSTEM WAS MODIFIED *****

但是，在出现此消息后重新运行 fsck 并不会损害文件系统。此消息只是有关 fsck 的更正操作的信息。

此过程假定本地 CD 或网络引导服务器可用，从而可以从备用设备引导系统。

有关恢复坏的超级块的信息，请参见如何恢复坏的超级块（仅限 Solaris 10 6/06 发行版）或如何恢复坏的超级块（Solaris 8、9 和 10 发行版）。

  1. 成为超级用户或承担等效角色。

  2. 仅适用于具有镜像根 (/) 文件系统的系统：在从备用设备进行引导之前分离根 (/) 镜像，否则会有损坏文件系统的风险。

    有关分离根 (/) 镜像的信息，请参见《Solaris Volume Manager 管理指南》中的“处理子镜像”。

  3. 识别需要检查的根 (/)、/usr 或 /var 文件系统的设备，例如 /dev/dsk/c0t0d0s0。

    从备用设备进行引导时，将需要提供此设备名称。已从备用设备引导后识别此设备会更困难。

  4. 在单用户模式下，从备用设备（如本地 CD 或网络）引导具有需要检查的根 (/)、/usr 或 /var 文件系统的系统。

    这样做可确保在这些文件系统上没有任何活动。

    例如：


    # init 0

ok boot net -s

.

.

.

#

  5. 检查包含步骤 3 中识别的根 (/)、/usr 或 /var 文件系统的设备。

    如果要检查或修复的文件系统的硬件已更改，则设备名称可能已更改。检查 fsck -n 消息 Last Mounted on ... 是否指示文件系统的预期设备。

    在此示例中，要检查的根 (/) 文件系统是 /dev/dsk/c0t0d0s0。 


    # fsck -n /dev/rdsk/c0t0d0s0

** /dev/rdsk/c0t0d0s0 (NO WRITE)

** Last Mounted on /

.

.

.

fsck /dev/rdsk/c0t0d0s0

** /dev/rdsk/c0t0d0s0

** Last Mounted on /

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

.

.

.

  6. 更正任何报告的 fsck 错误。

    有关如何响应以交互方式检查一个或多个 UFS 文件系统时出现的错误消息，请参见《系统管理指南：高级管理》中的第 28  章 “解决 UFS 文件系统不一致问题（任务）”。

  7. 如果在运行 fsck 后无法修复所有问题，请参见修复 fsck 命令无法修复的 UFS 文件系统。。

  8. 挂载已修复的文件系统，以确定 lost+found 目录中是否存在任何文件。

    由 fsck 命令放置在 lost+found 目录中的各个文件是使用其 inode 编号重命名的。如有可能，请重命名这些文件，并将它们移动到所属的位置。请尝试使用 grep 命令匹配各个文件中的短语，并尝试使用 file 命令确定文件类型。

    最后，删除遗留在 lost+found 目录中的无法识别的文件或目录，以免该目录不必要地被填满。

  9. 使系统返回到多用户模式。


    # init 6

  10. 仅适用于具有镜像根 (/) 文件系统的系统：重新连接根 (/) 镜像。

Procedure如何检查其他文件系统（不是根 (/)、/usr 或 /var）

有关 Solaris 10 6/06 发行版中 fsck 的新信息，请参见UFS 文件系统实用程序（fsck、mkfs 和 newfs）的增强功能。如果看到以下消息，则无需重新运行 fsck：


***** FILE SYSTEM WAS MODIFIED *****

但是，在出现此消息后重新运行 fsck 并不会损害文件系统。此消息只是有关 fsck 的更正操作的信息。

此过程假定已取消挂载要检查的文件系统。

有关恢复坏的超级块的信息，请参见如何恢复坏的超级块（仅限 Solaris 10 6/06 发行版）或如何恢复坏的超级块（Solaris 8、9 和 10 发行版）。

  1. 成为超级用户或承担等效角色。

  2. 取消挂载本地文件系统以确保文件系统上没有任何活动。

    将挂载点目录或 /dev/dsk/device-name 指定为 fsck 命令的参数。将显示有关不一致性问题的所有消息。

    例如：


    # umount /export/home

# fsck /dev/rdsk/c0t0d0s7

** /dev/dsk/c0t0d0s7

** Last Mounted on /export/home

.

.

.

  3. 更正任何报告的 fsck 错误。

    有关如何响应以交互方式检查一个或多个 UFS 文件系统时出现的错误消息，请参见《系统管理指南：高级管理》中的第 28  章 “解决 UFS 文件系统不一致问题（任务）”。

  4. 如果在运行 fsck 后无法修复所有问题，请参见修复 fsck 命令无法修复的 UFS 文件系统。。

  5. 挂载已修复的文件系统，以确定 lost+found 目录中是否存在任何文件。

    由 fsck 命令放置在 lost+found 目录中的单独文件是使用其 inode 编号重命名的。

  6. 重命名并移动放置在 lost+found 目录中的任何文件。

    如有可能，请重命名这些文件，并将它们移动到所属的位置。请尝试使用 grep 命令匹配各个文件中的短语，并尝试使用 file 命令确定文件类型。

    最后，删除遗留在 lost+found 目录中的无法识别的文件或目录，以免该目录不必要地被填满。

示例 22–1 以交互方式检查非根 (/) 或非 /usr 文件系统

以下示例说明如何检查 /dev/rdsk/c0t0d0s6 文件系统并更正不正确的块计数。此示例假定已取消挂载文件系统。


# fsck /dev/rdsk/c0t0d0s6

** Phase 1 - Check Block and Sizes

INCORRECT BLOCK COUNT I=2529 (6 should be 2)

CORRECT? y



** Phase 2 - Check Pathnames

** Phase 3 - Check Connectivity

** Phase 4 - Check Reference Counts

** Phase 5 - Cylinder Groups

929 files, 8928 used, 2851 free (75 frags, 347 blocks, 0.6%

fragmentation)

 

***** FILE SYSTEM WAS MODIFIED *****

#

整理 UFS 文件系统

fsck -o p 命令（p 表示整理）检查 UFS 文件系统，并自动解决通常因系统意外关闭而导致的问题。如果此命令遇到要求操作员干预的问题，则它会立即退出。此命令还允许并行检查文件系统。

在异常关机后，可以运行 fsck -o p 命令以整理文件系统。在此模式下，fsck 命令不查看“干净”标志，而是执行完整检查。这些操作是 fsck 命令以交互方式运行时所执行操作的子集。

Procedure如何整理 UFS 文件系统

此过程假定文件系统已取消挂载或处于非活动状态。

  1. 成为超级用户或承担等效角色。

  2. 取消挂载 UFS 文件系统。


    # umount /mount-point

  3. 用整理选项检查 UFS 文件系统。


    # fsck -o p /dev/rdsk/device-name

    通过将 /mount-point 或 /dev/rdsk/device-name 用作 fsck 命令的参数，可以整理单独的文件系统。

示例 22–2 整理 UFS 文件系统

以下示例说明如何整理 /export/home 文件系统。


# fsck -o p /export/home

修复 fsck 命令无法修复的 UFS 文件系统。

fsck 命令运行若干遍，在稍后的一遍中更正的问题可能会暴露仅在前几遍中检测到的其他问题。因此，有时需要一直运行 fsck，直到它不再报告任何问题。这样做可确保找出并修复所有错误。

请注意 fsck 命令所显示的信息。此信息可能有助于您解决问题。例如，消息可能会指出损坏的目录。如果删除该目录，则可能发现 fsck 命令不再报告任何错误。

如果 fsck 命令仍无法修复文件系统，请尝试使用 ff、clri 和 ncheck 命令找出并修复问题。有关如何使用这些命令的信息，请参见以下内容：

最后，可能需要重新创建文件系统，然后从备份介质恢复其内容。

有关恢复完整文件系统的信息，请参见第 27 章，恢复文件和文件系统（任务）。

如果无法完全修复文件系统，但可以将它挂载为只读，请尝试使用 cp、tar 或 cpio 命令从文件系统检索所有数据或部分数据。

如果问题是由硬件磁盘错误导致的，则在重新创建和恢复文件系统之前，可能需要再次重新格式化磁盘并对其重新分区。在更换磁盘设备之前，请检查设备电缆和连接器是否正常工作。硬件错误通常会在使用不同的命令时一再显示同一错误。format 命令尝试修复磁盘上的坏块。但是，如果磁盘损坏得太严重，则问题可能会一直存在，即使重新格式化后也是如此。有关使用 format 命令的信息，请参见 format(1M)。有关安装新磁盘的信息，请参见第 13 章，SPARC：添加磁盘（任务）或第 14 章，x86：添加磁盘（任务）。

恢复坏的超级块

当文件系统的超级块损坏时，必须恢复它。fsck 命令会在超级块已损坏的时候告知您。好在文件系统中存储有超级块的多个副本。

可以使用 fsck -o b 命令将超级块替换为其中一个副本，或使用 fsck 的自动搜索备份超级块功能（Solaris 10 6/06 发行版中的新增功能）。有关此功能的更多信息，请参见自动搜索备份超级块。

有关超级块的更多信息，请参见超级块。

如果根 (/) 文件系统中的超级块损坏，而且您无法恢复它，则您有以下两种选择：

Procedure如何恢复坏的超级块（仅限 Solaris 10 6/06 发行版）

此过程是 Solaris 10 6/06 发行版的新增内容。如果文件系统具有坏的超级块，则 fsck 会自动计算备用超级块，如以下消息所示：


BAD SUPERBLOCK AT ...



LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? 

LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS?
注意 – 注意 –

如果具有损坏的超级块的文件系统是使用 newfs 或 mkfs 自定义参数（例如 ntrack 或 nsect）创建的，则使用 fsck 自动计算的超级块执行修复过程可能会对文件系统造成无法恢复的损坏。

如果文件系统是使用自定义参数创建的，并且它具有坏的超级块，则 fsck 提供以下提示以取消 fsck 会话：


CANCEL FILESYSTEM CHECK?

如果此文件系统是使用自定义参数创建的，或者在此文件系统上运行 fsck 可能会带来其他问题，则应取消 fsck 会话。

  1. 成为超级用户或承担等效角色。

  2. 检查怀疑有坏的超级块的文件系统。


    # fsck /dev/rdsk/c0t1d0s0



** /dev/rdsk/c0t1d0s0



BAD SUPERBLOCK at ...

  3. 确定文件系统是如何创建的，然后选择以下项之一：

    • 文件系统是使用 newfs 命令创建的。

      • fsck 响应所有超级块都已损坏，而且必须使用通用超级块。按以下示例所示应答 fsck 提示。

        注意 – 注意 –

        如果文件系统是使用自定义参数创建的，则不要使用此选项。仅应在没有其他方法时使用此选项。为从备份副本恢复文件系统做好准备。


        # fsck /dev/dsk/c1t2d0s0

** /dev/rdsk/c1t2d0s0

BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED



LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? no





LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? yes



SEARCH FOR ALTERNATE SUPERBLOCKS FAILED.



USE GENERIC SUPERBLOCK FROM MKFS? no





USE GENERIC SUPERBLOCK FROM NEWFS? yes



CALCULATED GENERIC SUPERBLOCK WITH NEWFS

If filesystem was created with manually-specified geometry, using

auto-discovered superblock may result in irrecoverable damage to

filesystem and user data.



CANCEL FILESYSTEM CHECK? no



** Last Mounted on

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3a - Check Connectivity

** Phase 3b - Verify Shadows/ACLs

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cylinder Groups

CORRECT GLOBAL SUMMARY

SALVAGE? y





UPDATE STANDARD SUPERBLOCK? y



81 files, 3609 used, 244678 free (6 frags, 30584 blocks, 0.0% fragmentation)



***** FILE SYSTEM WAS MODIFIED *****

      • fsck 响应它找到备用超级块，并显示与以下内容类似的消息：


        FOUND ALTERNATE SUPERBLOCK 32 WITH NEWFS

        在此 fsck 方案中，按照自动搜索备份超级块所示的提示操作。

    • 文件系统是使用 mkfs 命令创建的。

      • fsck 响应所有超级块都已损坏，而且必须使用通用超级块。按以下示例所示应答 fsck 提示。

        注意 – 注意 –

        如果文件系统是使用自定义参数创建的，则不要使用此选项。仅应在没有其他方法时使用此选项。为从备份副本恢复文件系统做好准备。


        # fsck /dev/dsk/c1t2d0s0

** /dev/rdsk/c1t2d0s0

BAD SUPERBLOCK AT BLOCK 16: BLOCK SIZE LARGER THAN MAXIMUM SUPPORTED



LOOK FOR ALTERNATE SUPERBLOCKS WITH MKFS? yes





LOOK FOR ALTERNATE SUPERBLOCKS WITH NEWFS? no



SEARCH FOR ALTERNATE SUPERBLOCKS FAILED.



USE GENERIC SUPERBLOCK FROM MKFS? yes



CALCULATED GENERIC SUPERBLOCK WITH MKFS

If filesystem was created with manually-specified geometry, using

auto-discovered superblock may result in irrecoverable damage to

filesystem and user data.



CANCEL FILESYSTEM CHECK? no



** Last Mounted on

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3a - Check Connectivity

** Phase 3b - Verify Shadows/ACLs

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cylinder Groups

CORRECT GLOBAL SUMMARY

SALVAGE? y





UPDATE STANDARD SUPERBLOCK? y



81 files, 3609 used, 243605 free (117 frags, 30436 blocks, 0.0% fragmentation)

      • fsck 响应它找到备用超级块，并显示与以下内容类似的消息：


        FOUND ALTERNATE SUPERBLOCK 32 WITH MKFS

        在此 fsck 方案中，按照自动搜索备份超级块所示的提示操作。

  4. 应答提示以挽救和恢复超级块。

    在看到以下消息时，无需重新运行 fsck：


    ***** FILE SYSTEM WAS MODIFIED *****

    但是，在出现此消息后重新运行 fsck 并不会损害文件系统。此消息只是有关 fsck 的更正操作的信息。

Procedure如何恢复坏的超级块（Solaris 8、9 和 10 发行版）

  1. 成为超级用户或承担等效角色。

  2. 确定根 (/)、/usr 或 /var 文件系统中是否存在坏的超级块，然后选择以下项之一：

  3. 使用 newfs -N 命令显示超级块的值。


    # newfs -N /dev/rdsk/device-name

    除非文件系统是使用特殊参数创建的，否则命令输出将显示 newfs 命令创建文件系统时用于超级块副本的块编号。有关创建自定义文件系统的信息，请参见自定义 UFS 文件系统参数。

  4. 使用 fsck 命令提供备用超级块。


    # fsck -F ufs -o b=block-number /dev/rdsk/device-name

    fsck 命令使用指定的备用超级块恢复主超级块。可以始终尝试将 32 作为备用块。或者，使用 newfs -N 命令所示的任何备用块。

示例 22–3 恢复坏的超级块（Solaris 8、9 和 10 发行版）

以下示例说明如何恢复超级块副本 5264。 


# newfs -N /dev/rdsk/c0t3d0s7

/dev/rdsk/c0t3d0s7: 163944 sectors in 506 cylinders of 9 tracks, 36 sectors

 83.9MB in 32 cyl groups (16 c/g, 2.65MB/g, 1216 i/g)

super-block backups (for fsck -b #) at:

 32, 5264, 10496, 15728, 20960, 26192, 31424, 36656, 41888,

 47120, 52352, 57584, 62816, 68048, 73280, 78512, 82976, 88208,

 93440, 98672, 103904, 109136, 114368, 119600, 124832, 130064, 135296,

 140528, 145760, 150992, 156224, 161456,

# fsck -F ufs -o b=5264 /dev/rdsk/c0t3d0s7

Alternate superblock location: 5264.

** /dev/rdsk/c0t3d0s7

** Last Mounted on

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3 - Check Connectivity

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cyl groups

36 files, 867 used, 75712 free (16 frags, 9462 blocks, 0.0% fragmentation)



***** FILE SYSTEM WAS MODIFIED *****

#

fsck 命令的语法和选项

fsck 命令检查和修复文件系统中的不一致性问题。如果运行不带任何选项的 fsck 命令，则该命令会在进行修复之前以交互方式要求进行确认。此命令有四个选项。

命令和选项 

说明 

fsck -m

检查是否可以挂载文件系统 

fsck -y

接受所有修复 

fsck -n

拒绝所有修复 

fsck -o p

以非交互方式整理文件系统，解决所有预期的（无害的）不一致性问题，但是在遇到严重问题时退出