第一部分磁盘的物理组成
磁盘的基本概念：
扇区为最小的物理存储单位，每个扇区为512字节。
将扇区组成一个圆，那就是柱面，柱面是分区的最小单位。
第一个扇区很重要，里面有硬盘主引导记录（Masterbootrecord,MBR）及分区表，其中MBR占有446字节，分区表占有64字节。分区结构体如下的结构体如下：
struct partition{
u8 drive; // 0x80
u8 head;
u8 sector;
u8 cylinder;
u8 sys_type; //分区类型 5为扩展分区
u8 end_head;
u8 end_sector;
u8 end_cylinder;
u32 start_sector; //起始扇区开始计数的第n个扇区
u32 nr_sectors; //分区中的扇区个数
}
各种接口的磁盘在Linux中的文件名
①/dev/sd[a-p][1-15]:为SCSI，SATA，USB，Flash等接口的磁盘文件名；
②/dev/hd[a-d][1-63]:为IDE接口的磁盘文件名。
磁盘分区是告诉操作系统“我这块磁盘在此分区可以访问的区域是A柱面到B柱面之间的块”，这样操作系统就知道它可以在所指定的块内进行文件数据的读、写、查找等操作。磁盘分区即指定分区的起始与结束柱面。
而指定分区的柱面范围记录在第一个扇区的分区表中。因为分区表只有64字节（每个分区项占用16个字节，这16个字节中存有活动状态标志、文件系统标识、起止柱面号、磁头号、扇区号、隐含扇区数目(4个字节)、分区总扇区数目(4个字节)等内容。），所以最多只能记录4条分区的记录，这四条记录称为主分区或扩展分区。扩展分区还可以再分出逻辑分区。扩展分区最多只能有一个（操作系统限制），主分区和逻辑分区的内容可以被格式化，而扩展分区不能格式化。
注：MBR分区方案无法支持超过2TB容量的磁盘。因为这一方案用4个字节存储分区的总扇区数，最大能表示2的32次方的扇区个数，按每扇区512字节计算，每个分区最大不能超过2TB。磁盘容量超过2TB以后，分区的起始位置也就无法表示了。
一个磁盘可以划分成多个分区，每个分区必须先用格式化工具（如mkfs命令）格式化成某种格式的文件系统，然后才能存储文件，格式化过程中会在磁盘上写一些管理存储布局的信息。一个分区只能格式化成一个文件系统
文件系统特性
我们都知道磁盘分区完毕后还需要进行格式化(format)，之后操作系统才能够使用这个分区。 为什么需要进行『格式化』呢？这是因为每种操作系统所配置的文件属性/权限并不相同， 为了存放这些文件所需的数据，因此就需要将分区进行格式化，以成为操作系统能够利用的『文件系统格式(filesystem)』。
传统的磁盘与文件系统之应用中，一个分区就是只能够被格式化成为一个文件系统，所以我们可以说一个 filesystem 就是一个 partition。但是由于新技术的利用，例如我们常听到的LVM与软件磁盘阵列(software raid)， 这些技术可以将一个分区格式化为多个文件系统(例如LVM)，也能够将多个分区合成一个文件系统(LVM, RAID)！ 所以说，目前我们在格式化时已经不再说成针对 partition 来格式化了， 通常我们可以称呼一个可被挂载的数据为一个文件系统而不是一个分区。
那么文件系统是如何运行的呢？这与操作系统的文件数据有关。较新的操作系统的文件数据除了文件实际内容外， 通常含有非常多的属性，例如 Linux 操作系统的文件权限(rwx)与文件属性(拥有者、群组、时间参数等)。 文件系统通常会将这两部份的数据分别存放在不同的区块，权限与属性放置到 inode 中，至于实际数据则放置到 data block 区块中。 另外，还有一个超级区块 (superblock) 会记录整个文件系统的整体信息，包括 inode 与 block 的总量、使用量、剩余量等。
每个 inode 与 block 都有编号，至于这三个数据的意义可以简略说明如下：
superblock：记录此 filesystem 的整体信息，包括inode/block的总量、使用量、剩余量， 以及文件系统的格式与相关信息等；
inode：记录文件的属性，一个文件占用一个inode，同时记录此文件的数据所在的 block 号码；
block：实际记录文件的内容，若文件太大时，会占用多个 block 。
ext2文件系统
文件系统中存储的最小单元是块（block），一个块的大小是在格式化时确定的。启动块(Boot Block)的大小为1KB，由PC标准规定，用来存储磁盘分区信息和启动信息，任何文件系统都不能修改启动块。
启动块之后才是ext2文件系统的开始，ext2文件系统将整个分区划分成若干个同样大小的块组(Block Group)。
在整体的规划当中，文件系统最前面有一个启动扇区(boot sector)，这个启动扇区可以安装启动管理程序， 这是个非常重要的设计，因为如此一来我们就能够将不同的启动管理程序安装到个别的文件系统最前端，而不用覆盖整颗硬盘唯一的 MBR， 这样也才能够制作出多重引导的环境啊！至于每一个区块群组(block group)的六个主要内容说明如后：
每个块组的组成：
1）超级块(Super Block)描述整个分区的文件系统信息，如inode/block的大小、总量、使用量、剩余量，以及文件系统的格式与相关信息。超级块在每个块组的开头都有一份拷贝（第一个块组必须有，后面的块组可以没有）。 为了保证文件系统在磁盘部分扇区出现物理问题的情况下还能正常工作，就必须保证文件系统的super block信息在这种情况下也能正常访问。所以一个文件系统的super block会在多个block group中进行备份，这些super block区域的数据保持一致。
超级块记录的信息有：
1、block 与 inode 的总量（分区内所有Block Group的block和inode总量）；
2、未使用与已使用的 inode / block 数量；
3、block 与 inode 的大小 (block 为 1, 2, 4K，inode 为 128 bytes)；
4、filesystem 的挂载时间、最近一次写入数据的时间、最近一次检验磁盘 (fsck) 的时间等文件系统的相关信息；
5、一个 valid bit 数值，若此文件系统已被挂载，则 valid bit 为 0 ，若未被挂载，则 valid bit 为 1 。
struct ext2_super_block {
__u32 s_inodes_count;
__u32 s_blocks_count;
__u32 s_r_blocks_count;
__u32 s_free_blocks_count;
__u32 s_free_inodes_count;
__u32 s_first_data_block;
__u32 s_log_block_size;
__u32 s_log_clusters_size;
__u32 s_log_block_per_group ;
__u32 s_log_clusters_per_group ;
__u32 s_log_inodes_per_group;
__u32 s_mtime;
__u32 s_wtime;
__u16 s_mnt_count;
__s16 s_max_mnt_count;
__u16 s_magic;
...
__u16 s_inode_size;
} 每个区段与 superblock 的信息都可以使用 dumpe2fs 这个命令查询
2）块组描述符表(GDT,Group Descriptor Table)由很多块组描述符组成，整个分区分成多个块组就对应有多少个块组描述符。
每个块组描述符存储一个块组的描述信息，如在这个块组中从哪里开始是inode Table，从哪里开始是Data Blocks，空闲的inode和数据块还有多少个等等。块组描述符在每个块组的开头都有一份拷贝。
struct ext2_group_desc
{
__u32 bg_block_bitmap; /* Blocks bitmap block */
__u32 bg_inode_bitmap; /* Inodes bitmap block */
__u32 bg_inode_table; /* Inodes table block */
__u16 bg_free_blocks_count; /* Free blocks count */
__u16 bg_free_inodes_count; /* Free inodes count */
__u16 bg_used_dirs_count; /* Directories count */
__u16 bg_flags;
__u32 bg_exclude_bitmap_lo;/* Exclude bitmap for snapshots */
__u16 bg_block_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap)LSB */
__u16 bg_inode_bitmap_csum_lo;/* crc32c(s_uuid+grp_num+bitmap)LSB */
__u16 bg_itable_unused; /* Unused inodes count */
__u16 bg_checksum; /* crc16(s_uuid+grouo_num+group_desc)*/
};
3）块位图(Block Bitmap)用来描述整个块组中哪些块已用哪些块空闲。块位图本身占一个块，其中的每个bit代表本块组的一个block，这个bit为1代表该块已用，为0表示空闲可用。假设格式化时block大小为1KB，这样大小的一个块位图就可以表示1024*8个块的占用情况，因此一个块组最多可以有10248个块。
4）inode位图(inode Bitmap)和块位图类似，本身占一个块，其中每个bit表示一个inode是否空闲可用。 Inode bitmap的作用是记录block group中Inode区域的使用情况，Ext文件系统中一个block group中可以有16384个Inode，代表着这个Ext文件系统中一个block group最多可以描述16384个文件。
5）inode表(inode Table)由一个块组中的所有inode组成。一个文件除了数据需要存储之外，一些描述信息也需要存储，如文件类型，权限，文件大小，创建、修改、访问时间等，这些信息存在inode中而不是数据块中。inode表占多少个块在格式化时就要写入块组描述符中。 在Ext2/Ext3文件系统中，每个文件在磁盘上的位置都由文件系统block group中的一个Inode指针进行索引，Inode将会把具体的位置指向一些真正记录文件数据的block块，需要注意的是这些block可能和Inode同属于一个block group也可能分属于不同的block group。我们把文件系统上这些真实记录文件数据的block称为Data blocks。
Inode Table和单个Inode 结构
inode记录的文件数据至少有：（都是文件属性与权限描述信息）
该文件的访问模式（rwx）
该文件的所有者与组（owner/group）
该文件的大小
该文件创建或状态改变的时间（ctime）
最近一次的读取时间（atime）
最近修改内容的时间（mtime）
定义文件特性的标志（flag），如SetUID等
该文件真正内容的指向（Pointer）
Ext2/Ext3文件系统中，采用Inode指针和Data block地址进行直接/间接关联的方式记录文件数据。一个Inode指针要么不对应任何文件的Data block，要么对应一个文件的一个或者多个Data block。在Ext3文件系统中一个Inode指针的长度为4字节，按照一个字节8个bit计算Ext3文件系统中的Inode指针支持32位Data block寻址（2 ^ 32个地址）；到了Ext4文件系统，虽然它不再使用Inode指针，但同样有地址索引的概念，并且长度扩展到了6字节，那么按照一个字节8个bit计算，Ext4文件系统中的索引支持48位Data block寻址（2 ^ 48个地址）。所以如果按照单个Data block记录4KB数据大小来计算，Ext3文件系统支持的最大理论总容量就是：2 ^ 32 *4KB / 1024 / 1024 / 1024 = 16TB，而Ext4文件系统支持的最大理论总容量就是 2 ^ 48 *4KB / 1024 / 1024 / 1024 = 1,048,576TB = 1024 *1024TB。
Ext2/Ext3文件系统的Inode信息存放在block group的Inode Table区域，这个区域的默认大小为512个block，那么再根据文件系统中单个Inode的大小就可以得到每个block group所管理的Inode总数。例如当单位Inode的大小为256字节，得出每个block group所管理的Inode总数为 512 **4096字节 / 256字节 = 8192（Ext4文件系统）；当Inode的大小为128字节，得出每个block group所管理的Inode总数为 512 * 4096字节 / 128字节 = 16384 （Ext3文件系统）
inode 的数量与大小也是在格式化时就已经固定了，除此之外 inode 还有些什么特色呢？
每个 inode 大小均固定为 128 bytes；
每个文件都仅会占用一个 inode 而已；
承上，因此文件系统能够创建的文件数量与 inode 的数量有关；
系统读取文件时需要先找到 inode，并分析 inode 所记录的权限与用户是否符合，若符合才能够开始实际读取 block 的内容。
我们约略来分析一下 inode / block 与文件大小的关系好了。inode 要记录的数据非常多，但偏偏又只有 128bytes 而已， 而 inode 记录一个 block 号码要花掉 4byte ，假设我一个文件有 400MB 且每个 block 为 4K 时， 那么至少也要十万笔 block 号码的记录呢！inode 哪有这么多可记录的信息？为此我们的系统很聪明的将 inode 记录 block 号码的区域定义为12个直接，一个间接, 一个双间接与一个三间接记录区。这是啥？我们将 inode 的结构画一下好了。
数据块寻址：（ext2是索引式文件系统(indexed allocation)）
一个inode占128字节，其中60个字节用于指向存放文件内容的数据块指针。每个指针4字节，那么有15个指针。最后3个指针用分级间接寻址。
假设block为1KB。
12个直接指向，可以有12条记录。
一级间接寻址：1024/4=256，可以有256条记录。
二级间接寻址，可以有256* 256条记录。
三级间接寻址，可以有256 * 256 *256条记录。
所以对于1KB的块大小最大可以表示(256^3 +256^2+256+12)*1KB≈16GB的文件。
6）数据块(Data Block)是用来放置文件内容数据的地方。根据不同的文件类型有以下几种情况：
对于普通文件，文件的数据存储在数据块中。
对于目录，该目录下的所有文件名和目录名存储在所在目录的数据块中，除了文件名外，ls -l命令看到的其它信息保存在该文件的inode中。
对于符合链接，如果目标路径名较短则直接保存在inode中，如果较长则分配一个数据块来保存。
设备文件、FIFO和socket等特殊文件没有数据块。
data block 是用来放置文件内容数据地方，在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已。在格式化时 block 的大小就固定了，且每个 block 都有编号，以方便 inode 的记录啦。 不过要注意的是，由于 block 大小的差异，会导致该文件系统能够支持的最大磁盘容量与最大单一文件容量并不相同。 因为 block 大小而产生的 Ext2 文件系统限制如下：
Block 大小 1KB 2KB 4KB
最大单一文件限制 16GB 256GB 2TB
最大文件系统总容量 2TB 8TB 16TB
你需要注意的是，虽然 Ext2 已经能够支持大于 2GB 以上的单一文件容量，不过某些应用程序依然使用旧的限制， 也就是说，某些程序只能够捉到小于 2GB 以下的文件而已，这就跟文件系统无关了！
除此之外 Ext2 文件系统的 block 还有什么限制呢？有的！基本限制如下：
原则上，block 的大小与数量在格式化完就不能够再改变了(除非重新格式化)；
每个 block 内最多只能够放置一个文件的数据；
承上，如果文件大于 block 的大小，则一个文件会占用多个 block 数量；
承上，若文件小于 block ，则该 block 的剩余容量就不能够再被使用了(磁盘空间会浪费)。
如上第四点所说，由于每个 block 仅能容纳一个文件的数据而已，因此如果你的文件都非常小，但是你的 block 在格式化时却选用最大的 4K 时，可能会产生一些容量的浪费喔！我们以底下的一个简单例题来算一下空间的浪费吧！
例题：
假设你的Ext2文件系统使用 4K block ，而该文件系统中有 10000 个小文件，每个文件大小均为 50bytes， 请问此时你的磁盘浪费多少容量？
答：
由于 Ext2 文件系统中一个 block 仅能容纳一个文件，因此每个 block 会浪费『 4096 - 50 = 4046 (byte)』， 系统中总共有一万个小文件，所有文件容量为：50 (bytes) x 10000 = 488.3Kbytes，但此时浪费的容量为：『 4046 (bytes) x 10000 = 38.6MBytes 』。想一想，不到 1MB 的总文件容量却浪费将近 40MB 的容量，且文件越多将造成越多的磁盘容量浪费。
什么情况会产生上述的状况呢？例如 BBS 网站的数据啦！如果 BBS 上面的数据使用的是纯文本文件来记载每篇留言， 而留言内容如果都写上『如题』时，想一想，是否就会产生很多小文件了呢？
好，既然大的 block 可能会产生较严重的磁盘容量浪费，那么我们是否就将 block 大小订为 1K 即可？ 这也不妥，因为如果 block 较小的话，那么大型文件将会占用数量更多的 block ，而 inode 也要记录更多的 block 号码，此时将可能导致文件系统不良的读写效能。
所以我们可以说，在您进行文件系统的格式化之前，请先想好该文件系统预计使用的情况。 以鸟哥来说，我的数值模式仿真平台随便一个文件都好几百 MB，那么 block 容量当然选择较大的！至少文件系统就不必记录太多的 block 号码，读写起来也比较方便啊！
ext2写入过程
Linux操作系统为了加快I/O操作过程，当有文件需要写入文件系统时Linux操作系统并不会立刻将文件数据实际写入data block，而是存储到一个内存区块中。如果您通过top命令或者Free命令，就可以看到这个名叫cache memory的内存区块。
[root@lab-backup ~]# free
total used free shared buffers cached
Mem: 3805272 3662628 142644 508 1758376 1491128
-/+ buffers/cache: 413124 3392148
Swap: 3948540 0 3948540无论是Ext2文件系统还是Ext3文件系统又或者是Ext4文件系统，写入cache memory区块的这个过程是不会改变的。以上示例效果中还有一个叫做buffers memory的内存区块，这个区块缓存了文件系统的部分Inode信息，这样保证了操作系统不会随时到文件系统上寻找Inode——优化文件系统的读性能。cache memory区块和buffers memory区块由操作系统自行管理，它们只会使用当前没有被应用程序占用的空闲内存。当应用程序请求新的内存区块且空闲内存不够时，操作系统会释放部分cache memory区块或者buffers memory区块。后文我们讲解Linux下的Page Cache技术时，还会对这部分知识进行详细讲解。当cache memory区块写满或者到达一个等待时间后，操作系统就会正式开始向文件系统写数据了。
在Ext2文件系统中，完成文件写入的过程可以简要的进行如下描述：首先文件系统会在收到文件写入请求后根据算法寻找一个还没有使用的Inode，这个算法过程根据不同文件系统小版本和Linux内核版本的不同而有所变化，但寻找原则都是一样的，即尽可能为文件寻找连续的inode和data block。上文已经提到Ext文件系统中，每一个block group都有Block bitmap区域和Inode bitmap区域分别用于记录block group中的block和Inode的使用情况。在寻找Inode的这个步骤中，block group的Block bitmap、Inode bitmap区域还不会被写入任何变化，block group的Group description table区域也不会被写入任何变化。
接下来Ext2文件系统就要向硬件层正式写入数据了，这个步骤还包括建立Inode和data block的关联信息。最后当文件系统相对空闲的情况下，文件系统才会更新block group中的Block bitmap、Inode bitmap和Group description table区域。正常情况下这种操作过程并没有太大的问题，因为文件系统随时都清楚哪些Block bitmap、Inode bitmap被真正使用了，哪些Block bitmap、Inode bitmap是被使用但还没有来得及更改状态。当文件系统正常关闭时Ext2文件系统会设置一个校验标记Valid bit=1，表示本次文件系统的操作正常结束。
但是如果当文件系统因为各种原因异常关闭时（例如断电）这个标记的值就为0，那么问题就来了。因为哪些已经被使用但还没有来得及被标示的Block bitmap、Inode bitmap区域，和真实的使用情况就存在误差了。虽然操作系统下次启动时会对整个文件系统进行扫描试图恢复操作（主要目的是恢复Block bitmap、Inode bitmap和真实事情情况的一致性），但是操作系统并不保证一致性被全部恢复。这样看来Ext2文件系统的写入过程至少存在一下几个问题：
由于data block块的写入操作和Block bitmap、Inode bitmap区域的更新过程是分开进行的，所以当系统异常关闭时Ext2文件系统并不能保证Block bitmap、Inode bitmap的状态和真实的block使用情况完全一致。所以才会有系统重启时试图恢复磁盘一致性的修复操作。
Ext2文件系统对于大文件的读写性能并不好，这是因为当文件特别大时，Ext2文件系统会启用三级间接指针和四级间接指针建立Inode和data block的联系。虽然当data block size为4KB时单个文件的大小可达4TB，但是因为存储大文件时会启用二级、三级甚至四级间接指针，这大大增加了文件系统上的索引查找时间。所以这种多级索引的思路除了可以增加单个文件容量外，对提升大文件的读写性能实际上并没有太多帮助。
另外Ext2文件系统在向data block写入文件数据时，将以data block size（默认为4KB）为单位依次向硬件层提交数据，这就是为什么在其它设置不变的情况下，如果将Ext2文件系统的data block size格式化为8KB，会增加一定的磁盘读写性能的原因。
Ext3日志模式
以上小节中提到的Ext2文件系统的明显问题中，最严重的应该还是文件系统异常情况下Block bitmap、Inode bitmap可能出现的一致性问题。所以Ext3文件系统在基本保持Ext2文件系统组织结构的前提下，使用索引日志的思路来解决Ext2文件系统上的数据一致性问题。
Ext3文件系统又被称为日志文件系统，它在Ext2文件系统的基础上做的主要改动就是，在正式写入data block数据并建立Inode索引前，通过在磁盘上的某块固定位置写入一段日志数据的方式建立这两个操作过程的关系，并根据后续操作进行日志数据的保留/删除，以达到保持操作一致性的目的。这样一来，即使文件系统上一次异常关闭，当文件系统再次启动时也不需要再进行整个文件系统Inode和data block扫描了，只需要重新加载日志数据文件系统就可以知道上一次异常关闭时还有哪些Block bitmap、Inode bitmap没有处理完。
Ext3文件系统支持三种日志模式，他们在数据一致性和I/O性能上有所区别：
journal日志模式
在这种模式下，当文件系统正式开始进行磁盘操作前会在磁盘的上专门的日志区域创建这个文件的副本，包括这个文件的Inode和data block完整信息，副本创建完成后才会按照正常的写入过程进行文件写入。当写入操作正常完成后，文件系统会删除日志区域的文件副本。这样一来当文件系统发生异常并重启后，e2fsck检测程序会扫描日志区域中的副本：如果发现文件副本本身就不完整，则会丢弃这部分副本。如果发现文件副本是完整的，则会继续完成正式文件的写入过程，最后删除文件副本。很显然journal日志模式会增加单个文件的磁盘操作次数，所以journal日志模式是三种日志模式中速度最慢的一种。但是journal日志模式却可以做到最完整的数据一致性要求。
ordered日志模式
ordered日志模式是Ext3/Ext4文件系统默认的日志模式。这种模式比 journal日志模式快了许多，因为ordered日志模式下Ext文件系统的日志区域并没有真正记录文件的真实数据，不会发生一个文件的多次读写过程。当文件系统为新文件确定了Inode和block区域后，这些Inode、Block bitmap、Inode bitmap等索引信息将会首先保存到文件系统的日志区域，并形成一个事务单位。当文件数据被完整写入磁盘对应的block后，文件系统才会将日志区域的Inode信息和block信息提交到对应的block group中，完成整个写入过程。当文件系统发生异常并重启后，e2fsck检测程序会扫描日志区域中的副本：如果发现还有事务单位没有被提交，那么磁盘上对应的block位置上的信息将被清除，以保持文件信息一致性。
writeback日志模式
这是一种异步日志模式，文件系统的日志区域虽然也记录将写入磁盘的新文件的Inode、Block bitmap、Inode bitmap等索引信息。但是和ordered日志模式不同的是，这些日志信息记录过程和文件数据的写入过程没有先后关联，并且也不存在“提交”的概念。当文件系统发生异常并重启后，e2fsck检测程序也不会按照日志区域的数据状态进行一致性修复。writeback日志模式在大多数情况下能够提供最佳的Ext3/Ext4文件系统性能，因为日志功能几乎是关闭的。
从以上三种Ext3文件系统日志模式的简述中，可以发现的Ext3日志并不保证数据不丢失。实际上保证数据不丢失并不是Ext3日志的目标，而保证数据一致性才是Ext3日志的主要目标。为了达到这个目标，日志数据甚至会主动丢弃无法复原的副本数据。
设置文件系统日志级别
本小节介绍如何查看和设置Ext3/Ext4文件系统的日志模式。首先为了确定当前文件系统是否开启了日志模式，可以使用dumpe2fs命令进行查看：
# dumpe2fs /dev/sdb2
dumpe2fs 1.41.12 (17-May-2010)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0e94b563-8348-4056-8770-67fa34e2b903
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
......
Journal backup: inode blocks
Journal features: (none)
日志大小: 128M
Journal length: 32768
Journal sequence: 0x00000001
Journal start: 0
......
以下的block group信息可以忽略可以看到Filesystem features选项中有一个has_journal关键信息标识，这表示当前文件系统已经开启了日志功能。如果没有看到这个标记，则说明文件系统本身还没有开启日志功能——这种情况下Ext3文件系统就和Ext2文件系统没有太大区别了。
以下命令可以开启Ext3/Ext4文件系统的日志功能：
# tune2fs -O has_journal /dev/sdb2
tune2fs 1.41.12 (17-May-2010)
Creating journal inode: done以下命令可以关闭Ext3/Ext4文件系统的日志功能：
# tune2fs -O ^has_journal /dev/sdb2
tune2fs 1.41.12 (17-May-2010)但必须注意这并不表示指定了具体的日志模式，在开启了文件系统日志功能的情况下读者可以在使用mount进行具体挂载时指定日志模式。如下所示：
mount -o data=journal /dev/sdb2 /mnt/hgfs/
以上命令的data参数部分可以换成ordered、writeback和journal，代表文件系统支持的三种日志模式。设置完成后文件一同也完成了挂载。但是怎么检查日志模式设置是否成功呢？读者可以通过dmesg命令查看Linux系统的内核日志，在日志的最后一行会有最近一次的挂载信息，类似如下：
# dmesg
......
EXT3-fs (sdb2): using internal journal
EXT3-fs (sdb2): mounted filesystem with journal data mode
SELinux: initialized (dev sdb2, type ext3), uses xattr
可以看到内核日志信息的最后一行信息说明最近完成的内核变动操作，是按照journal日志模式挂载sdb2分区。当然内核日志信息包含了很多无用的信息，读者还可以通过以下命令索引出需要查看的信息：
# dmesg | grep -B 1 "mounted filesystem"
......
sd 2:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts:
--
Microcode Update Driver: v2.00 <[email protected]>, Peter Oruba
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts:
--
EXT3-fs (sdb2): using internal journal
EXT3-fs (sdb2): mounted filesystem with journal data mode
......当然最终我们还是要实现磁盘的永久挂载，这是就需要更改Linux操作系统中的/etc/fstab文件了。如果读者使用的是文件系统默认的ordered日志模式，则不需要在/etc/fstab文件中进行额外的设置。但如果不是这样的话，读者在设置/etc/fstab文件时，就要在其中的options列说明文件系统使用的日志模式。类似如下所示：
# vim /etc/fstab
......
/dev/sdb2 /mnt/hgfs ext3 data=journal 0 0
......