IBM文件系统操作指南.docx

— 文件系统崩溃的可能缘由 如电源意外中断，或应用程序正在对文件系统作读写操作时中断，重起时没有正常umount 文件系统都有可能造成文件系统的损坏，从浙江综合智能网SCP 的状况看应当是手工杀死数据库进程时，文件系统造成了不全都。 二 JFS 文件系统简介 假设发生系统崩溃，JFS 供给了快速文件系统重启。通过使用数据库日志技术，JFS 能在几秒或几分钟之内把文件系统恢复到全都状态，而非日志文件系统却要花上几小时甚至几天才能完成。 日志文件系统 (JFS) 供给了基于日志的字节级文件系统，该文件系统是为面对事务的高性能系统而开发的。它具有可伸缩性和强健性，与非日志文件系统相比，它的优点是其快速重启力量：JFS 能够在几秒或几分钟内就把文件系统恢复到全都状态。 虽然 JFS 主要是为满足效劳器〔从单处理器系统到高级多处理器和群集系统〕的高吞吐量和牢靠性需求而设计的，JFS 还可用于想得到高性能和牢靠性的客户机配臵。 规律卷 全部文件系统争论的根底是规律卷。一个JFS 文件系统唯一对应某一个规律卷。 聚拢和文件集 文件系统创立有用程序 mkfs，创立了完全包含在分区内的聚拢。聚拢是包含一种特定格式的磁盘块阵列，其格式包括超级块和安排映射表。超级块将分区标识成 JFS 聚拢，而安排映射表描述聚拢内每个数据块的安排状态。格式还包括描述它所必需的初始文件集和掌握构造。文件集是可安装的实体。 文件、名目、inode 与寻址构造 文件集包含文件和名目。文件和名目由 inode 持续表示；每个 inode 描述文件或名目的属性，并作为查找磁盘上文件或名目数据的起始点。JFS 还使用 inode 来表示其它文件系统对象，如描述文件集中每个 inode 的安排状态和磁盘位臵的映射表。 名目将用户特定的名称映射到为文件和名目所安排的 inode 上，并且形成传统的命名层次。文件包含用户数据，用户数据中没有隐含任何限制或格式。也就是说，JFS 将用户数据看成是未解释的字节流。根植于 inode 基于盘区的寻址构造用来将文件数据映射到磁盘。聚拢超级块和磁盘安排映射表、文件描述符和inode 映射表、inode、名目以及寻址构造一起表示了 JFS 掌握构造或元数据。 日志 在每个聚拢中维护 JFS 日志，并且用来记录元数据的操作信息。日志有一种同样由文件系统创立有用程序设臵的格式。聚拢内多个安装的文件集可以同时使用一个日志。AIX 系统日志在 ROOTVG 中默认是/dev/hd8。 设计特性 JFS 从一开头就设计成完全集成了日志记录，而不是在现有文件系统上添加日志记录。JFS 的很多特性使之区分于其它文件系统。 日志处理 JFS 供给了改进的构造化全都性和可恢复性，以及比非日志文件系统〔例如：HPFS、ext2 和传统 UNIX 文件系统〕快得多的系统重启时间。发生系统故障时非日志文件系统简洁崩溃，是由于一个规律写文件操作通常占用多个媒体 I/O 来完成，且在任何给定时间，可能没有完全反映在媒体上。这些文件系统依靠重启有用程序〔也就是 fsck〕，fsck 检查文件系统的全部元数据〔例如：名目和磁盘寻址构造〕以检测和修复构造完整性问题。这是一个耗时并且简洁出错的过程，在最糟糕的状况下，它还可能丧失或放错数据。 相反，JFS 使用原来为数据库开发的技术，记录了文件系统元数据上执行的操作〔即原子事务〕信息。假设发生系统故障，可通过重放日志并对适当的事务应用日志记录，来使文 件系统恢复到全都状态。由于重放有用程序只需检查文件系统最近活动所产生的运行记录， 而不是检查全部文件系统的元数据，因此，与这种基于日志的方法相关的文件系统恢复时间 要快得多。 基于日志恢复的其它几个方面也值得留意。首先，JFS 只记录元数据上的操作，因此， 重放这些日志只能恢复文件系统中构造关系和资源安排状态的全都性。它没有记录文件数 据，也没有将这些数据恢复到全都状态。因此，恢复后某些文件数据可能丧失或失效，对数据全都性有关键性需求的用户应当使用同步 I/O。 面对媒体出错，日志记录不是特别有效。特别地，在将日志或元数据写入磁盘的期间发生的 I/O 错误，意味着在系统崩溃后，要将文件系统恢复到全都状态，需要耗时并且有可能强加的全面完整性检查。这示意着，坏块重定位是任何驻留在 JFS 下的存储治理器或设备的一个关键特性。 JFS 日志记录的语义如下：当涉及元数据更改的文件系统操作--例如，unlink--返回成功执行的返回码时，操作的结果已经提交到文件系统，即使系统崩溃了也可以觉察。例如， 一旦成功删除了文件，即使系统崩溃然后重启，它仍旧是删除的并且不会再重消灭。 日志记录风格将同步写入日志磁盘引入每个修改元数据的 inode 或 vfs 操作。〔对数据库专家而言，这是一种使用非剥夺