test

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

以交互方式检查和修复 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：添加磁盘（任务）。