|
[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./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来达到目的。
对 data=journal 的调整
有些人在繁忙的服务器上 ― 特别是在繁忙的 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 秒（缺省值）刷新“脏”缓冲区。通过更有规律地将最近修改的数据刷新到磁盘，可以避免这些写操作的高峰。以这种方式执行的效率比较低，因为内核不太有机会组合写操作。但对于繁忙的服务器，写操作将更一致地进行，并将极大地改进交互式性能。
|
