摘要：
block size: 是文件系统最小的单位，Ext2/Ext3/Ext4 的区块大小可以是 1024、2048 或 4096 字节。 (Compaq Alpha 可
以使用 8192 字节区块) mke2fs 一般缺省会把小于 512 MiB 的文件系统使用 1024 字节区块格式化，等于或大于 512 MiB
的文件系统使用 4096 字节区块。(实际是视乎 mke2fs.conf 中文件系统类型 small 和 default 的设定 blocksize)
【即Ext2/Ext3/Ext4 的区块大小不是等于扇区的大小】
[root@fedora-12 ~]# tune2fs -l /dev/sda1
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 39f3f938-8732-4c3a-852d-c5377d44c85a
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg
sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1310720
Block count: 5241198
Reserved block count: 262059
Free blocks: 3784111
Free inodes: 1078711
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Dec 5 10:27:48 2009
Last mount time: Fri Dec 18 06:01:56 2009
Last write time: Fri Dec 18 06:01:56 2009
Mount count: 8
Maximum mount count: -1
Last checked: Sat Dec 5 10:27:48 2009
Check interval: 0 (<none>)
Lifetime writes: 8024 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 220551
Default directory hash: half_md4
Directory Hash Seed: a355fcab-6b06-4547-a090-134460e7985a
Journal backup: inode blocks
block size: 是文件系统最小的单位，Ext2/Ext3/Ext4 的区块大小可以是 1024、2048 或 4096 字节。 (Compaq Alpha 可
以使用 8192 字节区块) mke2fs 一般缺省会把小于 512 MiB 的文件系统使用 1024 字节区块格式化，等于或大于 512 MiB
的文件系统使用 4096 字节区块。(实际是视乎 mke2fs.conf 中文件系统类型 small 和 default 的设定 blocksize)
mkfs -t ext3 -b 4096 /dev/sdb5
super block:
inode: 索引节点，Ext2/Ext3 文件系统的 inode 数目限制了整个文件系统可能最多拥有的文件数目
mke2fs 缺省会根据文件系统的大小来决定 inode 的数目，小于或等于 512 MiB 的档系统会每 4kiB 有一个 inode，512
MiB 以上的文件系统则每 8kiB 有一个 inode。[1](实际是视乎 mke2fs.conf 中文件系统类型 small 和 default 的设定
inode_ratio)
要直接设定 inode 数目可以使用 mke2fs/mkfs.ext2/mkfs.ext3/mkfs 的选项 -N no-of-node，例如：
mke2fs -N 1000000 /dev/sdb5
mke2fs/mkfs.ext2/mkfs.ext3/mkfs 的选项 -i byte-per-inode 根据文件系统的大小来决定 inode 的数目，例如要文件系
统每 512 KiB 就有一个 inode，可以使用：
mke2fs -i 524288 /dev/sdb5 (byte-per-inode:每 512 KB 就由一个 inode来管理，多大的数据分一个inode ,比
blocksize更基础)
mkfs.ext3 -T news /dev/sdb5
Inode 大小 (inode size)
现时 inode 的大小缺省为 256 字节，早期的 inode 只有 128 字节。较大的 inode 令文件系统较易扩充支援 POSIX ACL
和扩充属性 (Extended Attrible) 等功能。inode 大小同样在格式化后不能改变。
您可以加上 -I inode-size 指定 inode 大小：
mkfs.ext3 -I 128 /dev/sdb5
保留空间
Ext2/Ext3 缺省保留 5% 硬盘空间供系统管理员工作之用。设定保留空间大小可以使用 mke2fs/mkfs.ext2/mkfs.ext3/mkfs
的选项 -m percentage，例如要文件系统保留 12% 的空间，可以使用：
mkfs.ext2 -m 12 /dev/sdb5
格式化后仍可以使用命令 tune2fs -m 或 tune2fs -r 改变。
侦察坏区块 (Bad block)
格式化时加上选项 -c，mke2fs 会扫描整个储存装置是否有坏区块 (bad block)，例如：
mkfs -t ext3 -c /dev/sdb6
如果使用选项 -cc，mke2fs 会写一此资料入储存装置每个区块并再读取来测式坏区块 - 比原本只读更准确和但更慢的方法
侦察坏区块，例如：
mkfs.ext2 -cc /dev/sdc1
日志大小 (Journal size)
格式化 ext3 或 ext4 时，mke2fs 会自动根据文件系统的大小划分日志 (journal) 的大小[2]：
* 少于 32,768 个区块则划分 1024 个区块作日志
* 少于 262,144 个区块但大于或等于 32,768 个区块则划分 4096 个区块作日志
* 大于或等于 262,144 个区块则划分 8192 个区块作日志
您可以加上 -J size=日志大小 指定建立的日志大小，单位为 MiB，例如：
mke2fs -J size=128 /dev/sdb1
格式化了 sdb1 为 ext3 并划分 128 MiB 的日志。(使用选项 -J 已稳示启用日志功能，所以可以略去选项 -j) 留意日志
的大小只可以为 1024 至 102,400 个区块。
William von Hagen[2]认为 mke2fs 自动划分的日志大小一般应该很适合，而无需要自订。日志过小会令其容易被写满，有
机会减低文件系统效率。较大的日志对启用 journaling 模式可能有帮助。但如果日志大于计算机实体内存大小，开机修复
文件系统时有机会不够内存加载整个日志纪录，不能自动修复。
如果有多于一颗硬盘，可以考虑使用外部日志 (external journal) 把文件系统和日志储存在不同的硬盘，可以增加效能。
文件系统类型 (fs-type)
e2fsprog 1.39 之前中的 mkfs.ext2/mkfs.ext3/mke2fs 只支援 news 、 largefile 和 largefile4 三个文件系统类型。
e2fsprog 1.39 开始， mkfs.ext2/mkfs.ext3/mke2fs 使用设定文件 mke2fs.conf 自订文件系统类型。[3] 现时一般
GNU/Linux 缺省的文件系统类型包括：
* small - 区块大小 1 KiB，每 4 KiB 一个 inode，inode 大小 128 字节
* floppy - 区块大小 1 KiB，每 8 KiB 一个 inode，inode 大小 128 字节
* news - 每 4 KiB 一个 inode
* largefile - 每 1 MiB 一个 inode
e2fsprogs 缺省的 mke2fs.conf 额外定义了 [4]：
* largefile4 - 每 4 MiB 一个 inode
* hurd - 区块大小 4 KiB，inode 大小 128 字节
* ext3 - 开启了 has_journal 功能
* ext4 - inode 大小 256 字节，开启了 has_journal、extents、huge_file、flex_bg、uninit_bg、dir_nlink 和
extra_isize 功能
文件系统标签 (Filesystem label)
文件系统标签 (Filesystem label) 在个别文件系统又叫作 Volume Name，是文件系统中一个小栏目用作简述该文件系统的
用途或其储存数据。现时 GNU/Linux 都会用 USB 手指/IEEE1394 硬盘等可移除储存装置的文件系统标签作为其挂载目录的
名称，方便使用者识别。而个别 GNU/Linux distribution 如 Fedora、RHEL 和 CentOS 等亦在 /etc/fstab 取代传统装置
文件名称 (即 /dev/sda1 和 /dev/hdc5 等) 的指定开机时要挂载的文件系统，避免偶然因为 BIOS 设定或插入次序的改变
而引起的混乱。您可以使用选项 -L 标签 在格式化时设定文件系统标签：
mkfs.ext2 -L Photos /dev/sdc1
Ext2/Ext3/Ext4 的文件系统标签不可以超过 16 个字符。往后可以使用命令 e2label 或 tune2fs -L 随时改变。
以下是使用命令 mke2fs/mkfs.ext2 格式化一个约 8 GiB 的分割区成为 Ext2 文件系统的画面：
# mke2fs /dev/sdb5
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
524288 inodes, 2096466 blocks (此例是个8GB的磁盘分区 2096466 x 4KB)
104823 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648 (最大2TB)
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
当中包括显示了有关新建 Ext2 文件系统的以下资讯：
* 区块大小 (Block size) - 上例为 4096 字节 (4 KiB)
* Fragment 大小 (Fragment size) - 实际上 Ext2/Ext3/Ext4 都不支援 fragment 功能，所以这值一定和区块大小一
样[5]
* inodes 数目 - 上例在整个文件系统建立了 524,288 个 inodes，亦是文件系统所可能拥有文件数目的上限
* 区块数目 (blocks) - 上例在整个文件系统建立了 2,096,466 个区块
* 保留区块 (reserved blocks) - 上例在整个文件系统保留了约 5% 的空间共 104,823 个区块 (约 409 MiB =
104,823 x 4 KiB) 给供系统管理员工作之用
* 文件系统区块数目上限 (Maximum Filesystem blocks) - 现时 Ext2/Ext3 所能支援一个文件系统所可能拥有区块数
目的上限，上例为 2,147,483,648。即表示文件系统大小上限为 8 TiB =2,147,483,648 x 4 KiB
* 区块组数目 (block groups) - 上例在整个文件系统建立了 64 个区块组
* 区块/组 (blocks per group) - 每个区块组的区块数目，为 32,768。个区块组约有 128 MiB = 32,768 * 4 KiB
* inodes/组 (inodes per group) - 每个区块组的 inodes 数目，为 8192
* Superblock 备份 (Superblock backups) - Superblock 被备份在编号 32768、98304、163840、229376、294912、
819200、884736 和 1605632 区块，即编号 1、3、5、7、9、25、27 和 49 区块组
此外，最尾两行亦显示文件系统的最大挂载次数 (Maxmimum Mount count) 为 21 和最大检查间距为 180 日，表示文件系
统每挂载超过 21 次或超过 180 日未有进行完整文件系统检查都会启动时进行完整检查。
为避免多个文件系统需要在同一次启动时进行完整文件系统检查，mke2fs 会在格式化文件系统时用一个乱数来设定最大挂
载次数 (Maxmimum Mount count) 的值，所以此值每次格式化时都不同。
以下是使用命令 mke2fs -j/mkfs.ext3/mkfs.ext4 格式化一个约 8 GiB 的分割区成为 Ext3 或 Ext4 文件系统的画面：
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
524288 inodes, 2096466 blocks
104823 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2147483648
64 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 27 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
和格式化 Ext2 的画面几乎相同，唯一分别只是多了个 “Creating journal” 建立日志的步骤罢了。此行同时显示日志的
大小，上例为 32,768 个区块 (128 MiB = 32,768 * 4 KiB)。
inode到底怎样计算其数目以及怎样改变其数目
Johnwoolee打电话问我如何计算一个固定大小的分区的inodes个数，也就是inodes和blocksize之间的计算关系。
我记得以前我接触过这个问题，记得和一个比率参数有关系。再次参看mkfs.ext3的man手册，记忆唤起来了，同时也增加了
新的认识。
mkfs.ext3缺省情况下，是根据blocksize和bytes-per-inode来计算出一个文件系统在格式化时有多少inodes的。不过，我
觉得应该之和bytes-per-inode有关，因为mkfs.ext3会根据每一个bytes-per-inode大小来创建一个inode，因此刨除保留块
，超级块外，一个分区剩下的大小除以这个bytes-per-inode就大约是inode的个数。
我做了一个实验，3GB大小的磁盘，分别指定blocksize和bytes-per-inode，得到的inode个数列表如下：
---------------------------------------------------------------------------------------
blocksize bytes-per-inode number-inode
---------------------------------------------------------------------------------------
1024 1024 3072000
---------------------------------------------------------------------------------------
1024 2048 1536000
----------------------------------------------------------------------------------------
1024 4096 768000
----------------------------------------------------------------------------------------
2048 2048 1537088
----------------------------------------------------------------------------------------
2048 4096 768544
---------------------------------------------------------------------------------------
上面的实验数据可以得出下面的结论：
(bytes-per-inode) * (number-inode) =~ 3GB (filesystem size)
因为在mkfs.ext3中，blocksize最小为1024,而bytes-per-inode最小不能小于blocksize，因此指定bytes-per-inode为1024
可以获得最大inode个数。
当然，如果你还嫌不够，-N的参数也许能满足变态要求的你，-N表示你来指定希望的inodes个数，这下，你该满足了吧。
不过，也不是不限制的，我尝试指定filesystem size(bytes)个数时，报错了。
root@wgzhao:~# mkfs.ext3 -n -N 3145728000 /dev/sdb
mke2fs 1.40.3 (05-Dec-2007)
mkfs.ext3: inode_size (128) * inodes_count (3145728000) too big for a
filesystem with 768000 blocks, specify higher inode_ratio (-i)
or lower inode count (-N).
当满足inode_size * inodes_count的要求后，不一定能满足其他要求，比如
root@wgzhao:~# mkfs.ext3 -n -N 21420000 /dev/sdb
mke2fs 1.40.3 (05-Dec-2007)
/dev/sdb: Cannot create filesystem with requested number of inodes while setting up superblock
太大的inodes个数，导致超级块无法创建。
到底最大能为多少为inodes个数, 当不知道的时候，就穷举，我针对我的这个3GB空间大小，得到最后的最大inodes值，为
12255232
接下来就是看看12255232这个数字有什么秘密隐藏在里面了。
3145728000 / 12255232 = 256.68 ~= 256
也就是说折算成bytes-per-inode应该是256了。
这样的话，一个分区创建为ext3文件系统时，最大的inode个数大约是
filesystem size (bytes) / 256
为了验证这个结果，我继续做了一个测试，当我把分区扩大到4GB时，inode个数大约应该是
4294967296 / 256 = 16777216 个
# mkfs.ext3 -m 0 -n -N 16318465 /dev/sdb
mke2fs 1.40.3 (05-Dec-2007)
/dev/sdb: Cannot create filesystem with requested number of inodes while setting up superblock
# mkfs.ext3 -m 0 -n -N 16318464 /dev/sdb
mke2fs 1.40.3 (05-Dec-2007)
warning: 112 blocks unused.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
16318464 inodes, 1023888 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=270536704
498 block groups
2056 blocks per group, 2056 fragments per group
32768 inodes per group
Superblock backups stored on blocks:
2056, 6168, 10280, 14392, 18504, 51400, 55512, 100744, 166536, 257000,
499608, 705208
实际最大值为16318465，比我预计的小了很多。
4294967296 / 16318465 = 263.1 <256
我想中间的差距应该是超级块等信息占用了一些block吧，具体还不是太清楚。
顺便给出一个文件系统最大磁盘大小数据表
文件系统 文件大小限制 文件系统大小限制 (看格式化的信息，更加标准)
----------------------------------------------------------------------------------------------------
ext2/3(1K bs) 16448 MB (~ 16 GB) 2048 GB (= 2 TiB)
ext2/3(2k bs) 256 GB 8192 GB (= 8 TiB)
ext2/3(4k bs) 2048 GB (= 2 TiB) 8192 GB (= 8 TiB)
ext2/3(8k bs) 65568 GB (~ 64 TiB) 32768 GB (= 32 TiB)
ReiserFS 3.5 2 GB 16384 GB (= 16 TiB)
ReiserFS 3.6(knl2.4) 1 EB 16384 GB (= 16 TiB)
XFS 8 EiB 8 EiB
JFS(512 bs) 8 EiB 512 TiB
JFS(4k bs) 8 EiB 4 PiB
NFSv2 (client side) 2 GB 8 EiB
NFSv3 (client side) 8 EiB 8 EiB
------------------------------------------------------------------------------------------------------
http://wiki.debian.org.hk/w/Format_disk_as_Ext2,_Ext3_or_Ext4
ext3日志模式
data=journal日志模式:记录改变文件系统数据和元数据，写2次数据块
文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会，但是它需要很多额外的磁盘访问。例如，当一个新文件被创建时，它的所有数据块都必须复制一份作为日志记录。这是最安全和最慢的Ext3日志模式。
日志中记录包括所有改变文件系统的数据和元数据。它是三种ext3日志模式中最慢的，也是最安全的一种。每个变化需要写磁盘2次、日志写1次。所有新数据首先被写入日志，然后才被定位。意外发生过后，日志可以被重放，将数据与元数据带回一致状态。
ext3 被设计用来执行完整数据和元数据日志记录。在这种方式下（称之为“data=journal”方式），JBD 将所有对数据和元数据的更改都记录到文件系统中。因为数据和元数据都被记录，JBD 可以使用日志将元数据和数据恢复到一致状态。完整数据日志记录的缺点是它可能会比较慢，但可以通过设置相对较大日志来减少性能损失。
文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会，但是它需要很多额
data=ordered日志模式:先写数据块，再修改元数据
只有对文件系统元数据的改变才记入日志。然而，Ext3文件系统把元数据和相关的数据块进行分组，以便把元数据写入磁盘之前写入数据块。这样，就可以减少文件内数据损坏的机会；例如，确保增大文件的任何写访问都完全受日志的保护。这是缺省的Ext3 日志模式。
仅记录改变文件系统的元数据，且溢出文件数据要补充到磁盘中。这是缺省的ext3日志模式。文件数据的变化情况并不被记录在日志中，但它们必须做，而且由 ext3的daemon程序在与之相关的文件系统元数据变化前执行，即在记录元数据前要修改文件系统数据，这将稍微降低系统的性能（速度），然而可确保文件系统中的文件数据与相应文件系统的元数据同步。
ext3 添加了一种新的日志记录方式，该方式提供完整日志记录的好处而不会带来严重的性能损失。这种新方式只对元数据进行日志记录。但是，ext3 文件系统驱动程序保持对与每个元数据更新对应的特殊数据块的跟踪，将它们分组到一个称为事务的实体中。当事务应用于适当的文件系统时，数据块首先被写到磁盘。一旦写入数据块，元数据将随后写入日志。通过使用这种技术（称为“data=ordered”方式），即使只有元数据更改被记录到日志中，ext3 也能够提供数据和元数据的一致性。ext3 缺省使用这种方式。
data=writeback日志模式:也只是记录了元数据，同时写元数据和数据块，可能写了元数据，数据块还没写完。对文件数据的更新与记录元数据变化可以不同步。
只有对文件系统元数据的改变才记入日志；这是在其他日志文件系统发现的方法，也是最快的模式。
仅记录改变文件系统的元数据，但根据标准文件系统，写程序仍要将文件数据的变化记录在磁盘上，以保持文件系统一致性。这是速度最快的ext3日志模式。因为它只记录元数据的变化，而不需等待与文件数据相关的更新如文件大小、目录信息等情况，对文件数据的更新与记录元数据变化可以不同步，即ext3是支持异步的日志。缺陷是当系统关闭时，更新的数据因不能被写入磁盘而出现矛盾，这一点目前尚不能很好解决。
有趣的是，ext3 处理日志记录的方式与 ReiserFS 和其它日志记录文件系统所用的方式迥异。使用 ReiserFS、XFS 和 JFS 时，文件系统驱动程序记录元数据，但不提供 数据日志记录。使用 仅元数据日志记录，您的文件系统元数据将会异常稳固，因而可能永远不需要执行彻底 fsck。然而，意外的重新引导和系统锁定可能会导致最近修改数据的明显毁坏。Ext3 使用一些创新的解决方案来避免这些问题，我们将对此做稍微深入的研究。
但首先，重要的是确切理解仅元数据日志记录最终是如何危害您的。举例来说，假设您正在修改名为 /tmp/myfile.txt 的文件时，机器意外锁定，*需要重新引导。如果您使用的是仅元数据日志记录文件系统，譬如 ReiserFS、XFS 或者 JFS，文件系统元数据将容易地修复，这要感谢元数据日志，您不必耐着性子等待艰苦的 fsck 了。
但是，存在一种明显的可能性：在将 /tmp/myfile.txt 文件装入到文本编辑器时，文件不仅仅丢失最近的更改，而且还包含许多乱码甚至可能完全不可读的信息。这种情况并不总会发生，但它可能并且经常发生。
下面解释原因。典型的日志记录文件系统（譬如 ReiserFS、XFS 和 JFS）对元数据有特别处理，但是对数据不够重视。在上述示例中，文件系统驱动程序处于修改一些文件系统块的过程中。文件系统驱动程序更新适当的元数据，但是没有时间将其缓存中的数据刷新到磁盘的新块中。因此，当您将 /tmp/myfile.txt 文件装入文本编辑器时，文件的部分或全部包含乱码 ― 在系统锁定之前来不及初始化的数据块。
一般情况下，建议使用缺省模式。如果要改变模式，要在/etc/fstab文件中为相应的文件系统加上data=模式选项。
对于journal和writeback模式都可以调整这个参数会有帮助。ext3文件系统还涉及到如何cache中的数据刷到硬盘上。它是通过kupdate进程来实现定期刷的，默认是5秒检查一次，将超过30秒的脏数据刷到硬盘。在as 3.0中可以通过修改/proc/sys/vm/bdflush来达到目的。
有些人在繁忙的服务器上 ― 特别是在繁忙的 NFS 服务器上 ― 使用 ext3 的 data=journal 方式时曾经碰到一个特殊的性能问题。每隔 30 秒，服务器就会遇到磁盘写活动高峰，导致系统几乎陷于停顿。如果您遇到这个问题，修复它很容易。只要以 root 用户输入以下命令，就可以调整 Linux“脏”缓冲区刷新算法：
调整 bdflush
echo 40 0 0 0 60 300 60 0 0 > /proc/sys/vm/bdflush
这些新的 bdflush 设置将导致 kupdate 每隔 0.6 秒而不是每隔 5 秒运行。另外，它们告诉内核每隔 3 秒而不是 30 秒（缺省值）刷新“脏”缓冲区。通过更有规律地将最近修改的数据刷新到磁盘，可以避免这些写操作的高峰。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。
参考：
ext3 文件系统块大小 谷歌