本文来自:http://vbird.dic.ksu.edu.tw/linux_basic/0230filesystem.php
1. 认识 EXT2 文件系统
1.1 硬盘组成与分割的复习 1.2 文件系统特性: 索引式文件系统 1.3 Linux 的 EXT2 文件系统(inode): data block, inode table, superblock, dumpe2fs 1.4 与目录树的关系 1.5 EXT2/EXT3 文件的存取与日志式文件系统的功能 1.6 Linux 文件系统的运行 1.7 挂载点的意义 (mount point) 1.8 其他 Linux 支持的文件系统与 VFS 2. 文件系统的简单操作 2.1 磁盘与目录的容量: df, du 2.2 实体链接与符号链接: ln 3. 磁盘的分割、格式化、检验与挂载 3.1 磁盘分区: fdisk, partprobe 3.2 磁盘格式化: mkfs, mke2fs 3.3 磁盘检验: fsck, badblocks 3.4 磁盘挂载与卸除: mount, umount 3.5 磁盘参数修订: mknod, e2label, tune2fs, hdparm 4. 配置启动挂载: 4.1 启动挂载 /etc/fstab 及 /etc/mtab 4.2 特殊装置 loop 挂载(映象档不刻录就挂载使用) 5. 内存置换空间(swap)之建置: 5.1 使用实体分割槽建置swap 5.2 使用文件建置swap 5.3 swap使用上的限制 6. 文件系统的特殊观察与操作 6.1 boot sector 与 superblock 的关系 6.2 磁盘空间之浪费问题 6.3 利用 GNU 的 parted 进行分割行为 7. 重点回顾 8. 本章习题 9. 参考数据与延伸阅读 10. 针对本文的建议:http://phorum.vbird.org/viewtopic.php?t=23881 认识 EXT2 文件系统 Linux最传统的磁盘文件系统(filesystem)使用的是EXT2这个啦!所以要了解文件系统就得要由认识EXT2开始! 而文件系统是创建在硬盘上面的,因此我们得了解硬盘的物理组成才行。磁盘物理组成的部分我们在第零章谈过了,至于磁盘分区则在第三章谈过了,所以底下只会很快的复习这两部份。 重点在于inode, block还有superblock等文件系统的基本部分喔! 硬盘组成与分割的复习 由于各项磁盘的物理组成我们在第零章里面就介绍过, 同时第三章也谈过分割的概念了, 所以这个小节我们就拿之前的重点出来介绍就好了!详细的信息请您回去那两章自行复习喔!^_^。 好了,首先说明一下磁盘的物理组成,整颗磁盘的组成主要有:
从上面我们知道数据储存与读取的重点在于磁盘盘,而磁盘盘上的物理组成则为(假设此磁盘为单盘片, 磁盘盘图标请参考第三章图2.2.1的示意):
各种接口的磁盘在Linux中的文件名分别为:
复习完物理组成后,来复习一下磁盘分区吧!所谓的磁盘分区指的是告诉操作系统『我这颗磁盘在此分割槽可以存取的区域是由 A 磁柱到 B 磁柱之间的区块』, 如此一来操作系统就能够知道他可以在所指定的区块内进行文件数据的读/写/搜寻等动作了。 也就是说,磁盘分区意即指定分割槽的启始与结束磁柱就是了。 那么指定分割槽的磁柱范围是记录在哪里?就是第一个扇区的分割表中啦!但是因为分割表仅有64bytes而已, 因此最多只能记录四笔分割槽的记录,这四笔记录我们称为主要 (primary) 或延伸 (extended) 分割槽,其中扩展分配槽还可以再分割出逻辑分割槽 (logical) , 而能被格式化的则仅有主要分割与逻辑分割而已。 最后,我们再将第三章关于分割的定义拿出来说明一下啰:
文件系统特性 我们都知道磁盘分区完毕后还需要进行格式化(format),之后操作系统才能够使用这个分割槽。 为什么需要进行『格式化』呢?这是因为每种操作系统所配置的文件属性/权限并不相同, 为了存放这些文件所需的数据,因此就需要将分割槽进行格式化,以成为操作系统能够利用的『文件系统格式(filesystem)』。 由此我们也能够知道,每种操作系统能够使用的文件系统并不相同。 举例来说,windows 98 以前的微软操作系统主要利用的文件系统是 FAT (或 FAT16),windows 2000 以后的版本有所谓的 NTFS 文件系统,至于 Linux 的正统文件系统则为 Ext2 (Linux second extended file system, ext2fs)这一个。此外,在默认的情况下,windows 操作系统是不会认识 Linux 的 Ext2 的。 传统的磁盘与文件系统之应用中,一个分割槽就是只能够被格式化成为一个文件系统,所以我们可以说一个 filesystem 就是一个 partition。但是由于新技术的利用,例如我们常听到的LVM与软件磁盘阵列(software raid), 这些技术可以将一个分割槽格式化为多个文件系统(例如LVM),也能够将多个分割槽合成一个文件系统(LVM, RAID)! 所以说,目前我们在格式化时已经不再说成针对 partition 来格式化了, 通常我们可以称呼一个可被挂载的数据为一个文件系统而不是一个分割槽喔! 那么文件系统是如何运行的呢?这与操作系统的文件数据有关。较新的操作系统的文件数据除了文件实际内容外, 通常含有非常多的属性,例如 Linux 操作系统的文件权限(rwx)与文件属性(拥有者、群组、时间参数等)。 文件系统通常会将这两部份的数据分别存放在不同的区块,权限与属性放置到 inode 中,至于实际数据则放置到 data block 区块中。 另外,还有一个超级区块 (superblock) 会记录整个文件系统的整体信息,包括 inode 与 block 的总量、使用量、剩余量等。 每个 inode 与 block 都有编号,至于这三个数据的意义可以简略说明如下:
由于每个 inode 与 block 都有编号,而每个文件都会占用一个 inode ,inode 内则有文件数据放置的 block 号码。 因此,我们可以知道的是,如果能够找到文件的 inode 的话,那么自然就会知道这个文件所放置数据的 block 号码, 当然也就能够读出该文件的实际数据了。这是个比较有效率的作法,因为如此一来我们的磁盘就能够在短时间内读取出全部的数据, 读写的效能比较好啰。 我们将 inode 与 block 区块用图解来说明一下,如下图所示,文件系统先格式化出 inode 与 block 的区块,假设某一个文件的属性与权限数据是放置到 inode 4 号(下图较小方格内),而这个 inode 记录了文件数据的实际放置点为 2, 7, 13, 15 这四个 block 号码,此时我们的操作系统就能够据此来排列磁盘的阅读顺序,可以一口气将四个 block 内容读出来! 那么数据的读取就如同下图中的箭头所指定的模样了。 图1.2.1、inode/block 数据存取示意图 这种数据存取的方法我们称为索引式文件系统(indexed allocation)。那有没有其他的惯用文件系统可以比较一下啊? 有的,那就是我们惯用的闪盘(闪存),闪盘使用的文件系统一般为 FAT 格式。FAT 这种格式的文件系统并没有 inode 存在,所以 FAT 没有办法将这个文件的所有 block 在一开始就读取出来。每个 block 号码都记录在前一个 block 当中, 他的读取方式有点像底下这样: 图1.2.2、FAT文件系统数据存取示意图 上图中我们假设文件的数据依序写入1->7->4->15号这四个 block 号码中, 但这个文件系统没有办法一口气就知道四个 block 的号码,他得要一个一个的将 block 读出后,才会知道下一个 block 在何处。 如果同一个文件数据写入的 block 分散的太过厉害时,则我们的磁盘读取头将无法在磁盘转一圈就读到所有的数据, 因此磁盘就会多转好几圈才能完整的读取到这个文件的内容! 常常会听到所谓的『碎片整理』吧? 需要碎片整理的原因就是文件写入的 block 太过于离散了,此时文件读取的效能将会变的很差所致。 这个时候可以透过碎片整理将同一个文件所属的 blocks 汇整在一起,这样数据的读取会比较容易啊! 想当然尔,FAT 的文件系统需要经常的碎片整理一下,那么 Ext2 是否需要磁盘重整呢? 由于 Ext2 是索引式文件系统,基本上不太需要常常进行碎片整理的。但是如果文件系统使用太久, 常常删除/编辑/新增文件时,那么还是可能会造成文件数据太过于离散的问题,此时或许会需要进行重整一下的。 不过,老实说,鸟哥倒是没有在 Linux 操作系统上面进行过 Ext2/Ext3 文件系统的碎片整理说!似乎不太需要啦!^_^ Linux 的 EXT2 文件系统(inode): 在第六章当中我们介绍过 Linux 的文件除了原有的数据内容外,还含有非常多的权限与属性,这些权限与属性是为了保护每个用户所拥有数据的隐密性。 而前一小节我们知道 filesystem 里面可能含有的 inode/block/superblock 等。为什么要谈这个呢?因为标准的 Linux 文件系统 Ext2 就是使用这种 inode 为基础的文件系统啦! 而如同前一小节所说的,inode 的内容在记录文件的权限与相关属性,至于 block 区块则是在记录文件的实际内容。 而且文件系统一开始就将 inode 与 block 规划好了,除非重新格式化(或者利用 resize2fs 等命令变更文件系统大小),否则 inode 与 block 固定后就不再变动。但是如果仔细考虑一下,如果我的文件系统高达数百GB时, 那么将所有的 inode 与 block 通通放置在一起将是很不智的决定,因为 inode 与 block 的数量太庞大,不容易管理。 为此之故,因此 Ext2 文件系统在格式化的时候基本上是区分为多个区块群组 (block group) 的,每个区块群组都有独立的 inode/block/superblock 系统。感觉上就好像我们在当兵时,一个营里面有分成数个连,每个连有自己的联络系统, 但最终都向营部回报连上最正确的信息一般!这样分成一群群的比较好管理啦!整个来说,Ext2 格式化后有点像底下这样: 图1.3.1、ext2文件系统示意图( 注1) 在整体的规划当中,文件系统最前面有一个启动扇区(boot sector),这个启动扇区可以安装启动管理程序, 这是个非常重要的设计,因为如此一来我们就能够将不同的启动管理程序安装到个别的文件系统最前端,而不用覆盖整颗硬盘唯一的 MBR, 这样也才能够制作出多重引导的环境啊!至于每一个区块群组(block group)的六个主要内容说明如后:
data block 是用来放置文件内容数据地方,在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已。在格式化时 block 的大小就固定了,且每个 block 都有编号,以方便 inode 的记录啦。 不过要注意的是,由于 block 大小的差异,会导致该文件系统能够支持的最大磁盘容量与最大单一文件容量并不相同。 因为 block 大小而产生的 Ext2 文件系统限制如下:(注2)
你需要注意的是,虽然 Ext2 已经能够支持大于 2GB 以上的单一文件容量,不过某些应用程序依然使用旧的限制, 也就是说,某些程序只能够捉到小于 2GB 以下的文件而已,这就跟文件系统无关了! 举例来说,鸟哥在环工方面的应用中有一套秀图软件称为PAVE(注3), 这套软件就无法捉到鸟哥在数值模式仿真后产生的大于 2GB 以上的文件!害的鸟哥常常还要重跑数值模式... 除此之外 Ext2 文件系统的 block 还有什么限制呢?有的!基本限制如下:
如上第四点所说,由于每个 block 仅能容纳一个文件的数据而已,因此如果你的文件都非常小,但是你的 block 在格式化时却选用最大的 4K 时,可能会产生一些容量的浪费喔!我们以底下的一个简单例题来算一下空间的浪费吧!
什么情况会产生上述的状况呢?例如 BBS 网站的数据啦!如果 BBS 上面的数据使用的是纯文本文件来记载每篇留言, 而留言内容如果都写上『如题』时,想一想,是否就会产生很多小文件了呢? 好,既然大的 block 可能会产生较严重的磁盘容量浪费,那么我们是否就将 block 大小订为 1K 即可? 这也不妥,因为如果 block 较小的话,那么大型文件将会占用数量更多的 block ,而 inode 也要记录更多的 block 号码,此时将可能导致文件系统不良的读写效能。 所以我们可以说,在您进行文件系统的格式化之前,请先想好该文件系统预计使用的情况。 以鸟哥来说,我的数值模式仿真平台随便一个文件都好几百 MB,那么 block 容量当然选择较大的!至少文件系统就不必记录太多的 block 号码,读写起来也比较方便啊!
再来讨论一下 inode 这个玩意儿吧!如前所述 inode 的内容在记录文件的属性以及该文件实际数据是放置在哪几号 block 内! 基本上,inode 记录的文件数据至少有底下这些:(注4)
inode 的数量与大小也是在格式化时就已经固定了,除此之外 inode 还有些什么特色呢?
我们约略来分析一下 inode / block 与文件大小的关系好了。inode 要记录的数据非常多,但偏偏又只有 128bytes 而已, 而 inode 记录一个 block 号码要花掉 4byte ,假设我一个文件有 400MB 且每个 block 为 4K 时, 那么至少也要十万笔 block 号码的记录呢!inode 哪有这么多可记录的信息?为此我们的系统很聪明的将 inode 记录 block 号码的区域定义为12个直接,一个间接, 一个双间接与一个三间接记录区。这是啥?我们将 inode 的结构画一下好了。 图1.3.2、inode 结构示意图( 注5) 上图最左边为 inode 本身 (128 bytes),里面有 12 个直接指向 block 号码的对照,这 12 笔记录就能够直接取得 block 号码啦! 至于所谓的间接就是再拿一个 block 来当作记录 block 号码的记录区,如果文件太大时, 就会使用间接的 block 来记录编号。如上图 1.3.2 当中间接只是拿一个 block 来记录额外的号码而已。 同理,如果文件持续长大,那么就会利用所谓的双间接,第一个 block 仅再指出下一个记录编号的 block 在哪里, 实际记录的在第二个 block 当中。依此类推,三间接就是利用第三层 block 来记录编号啦! 这样子 inode 能够指定多少个 block 呢?我们以较小的 1K block 来说明好了,可以指定的情况如下:
此时我们知道当文件系统将 block 格式化为 1K 大小时,能够容纳的最大文件为 16GB,比较一下文件系统限制表的结果可发现是一致的!但这个方法不能用在 2K 及 4K block 大小的计算中, 因为大于 2K 的 block 将会受到 Ext2 文件系统本身的限制,所以计算的结果会不太符合之故。
Superblock 是记录整个 filesystem 相关信息的地方, 没有 Superblock ,就没有这个 filesystem 了。他记录的信息主要有:
Superblock 是非常重要的,因为我们这个文件系统的基本信息都写在这里,因此,如果 superblock 死掉了, 你的文件系统可能就需要花费很多时间去挽救啦!一般来说, superblock 的大小为 1024bytes。相关的 superblock 信息我们等一下会以dumpe2fs 命令来呼叫出来观察喔! 此外,每个 block group 都可能含有 superblock 喔!但是我们也说一个文件系统应该仅有一个 superblock 而已,那是怎么回事啊? 事实上除了第一个 block group 内会含有 superblock 之外,后续的 block group 不一定含有 superblock , 而若含有 superblock 则该 superblock 主要是做为第一个 block group 内 superblock 的备份咯,这样可以进行 superblock 的救援呢!
这个区段可以描述每个 block group 的开始与结束的 block 号码,以及说明每个区段 (superblock, bitmap, inodemap, data block) 分别介于哪一个 block 号码之间。这部份也能够用 dumpe2fs 来观察的。
如果你想要新增文件时总会用到 block 吧!那你要使用哪个 block 来记录呢?当然是选择『空的 block 』来记录新文件的数据啰。 那你怎么知道哪个 block 是空的?这就得要透过 block bitmap 的辅助了。从 block bitmap 当中可以知道哪些 block 是空的,因此我们的系统就能够很快速的找到可使用的空间来处置文件啰。 同样的,如果你删除某些文件时,那么那些文件原本占用的 block 号码就得要释放出来, 此时在 block bitmap 当中相对应到该 block 号码的标志就得要修改成为『未使用中』啰!这就是 bitmap 的功能。
这个其实与 block bitmap 是类似的功能,只是 block bitmap 记录的是使用与未使用的 block 号码, 至于 inode bitmap 则是记录使用与未使用的 inode 号码啰! 了解了文件系统的概念之后,再来当然是观察这个文件系统啰!刚刚谈到的各部分数据都与 block 号码有关! 每个区段与 superblock 的信息都可以使用 dumpe2fs 这个命令来查询的!查询的方法与实际的观察如下:
如上所示,利用 dumpe2fs 可以查询到非常多的信息,不过依内容主要可以区分为上半部是 superblock 内容, 下半部则是每个 block group 的信息了。从上面的表格中我们可以观察到这个 /dev/hdc2 规划的 block 为 4K, 第一个 block 号码为 0 号,且 block group 内的所有信息都以 block 的号码来表示的。 然后在 superblock 中还有谈到目前这个文件系统的可用 block 与 inode 数量喔! 至于 block group 的内容我们单纯看 Group0 信息好了。从上表中我们可以发现:
如果你对文件系统的详细信息还有更多想要了解的话,那么请参考本章最后一小节的介绍喔! 否则文件系统看到这里对于基础认知您应该是已经相当足够啦!底下则是要探讨一下, 那么这个文件系统概念与实际的目录树应用有啥关连啊? 与目录树的关系 由前一小节的介绍我们知道在 Linux 系统下,每个文件(不管是一般文件还是目录文件)都会占用一个 inode , 且可依据文件内容的大小来分配多个 block 给该文件使用。而由第六章的权限说明中我们知道目录的内容在记录文件名, 一般文件才是实际记录数据内容的地方。那么目录与文件在 Ext2 文件系统当中是如何记录数据的呢? 基本上可以这样说:
当我们在 Linux 下的 ext2 文件系统创建一个目录时, ext2 会分配一个 inode 与至少一块 block 给该目录。其中,inode 记录该目录的相关权限与属性,并可记录分配到的那块 block 号码; 而 block 则是记录在这个目录下的文件名与该文件名占用的 inode 号码数据。也就是说目录所占用的 block 内容在记录如下的信息: 图1.4.1、目录占用的 block 记录的数据示意图 如果想要实际观察 root 家目录内的文件所占用的 inode 号码时,可以使用 ls -i 这个选项来处理:
由于每个人所使用的计算机并不相同,系统安装时选择的项目与 partition 都不一样,因此你的环境不可能与我的 inode 号码一模一样!上表的左边所列出的 inode 仅是鸟哥的系统所显示的结果而已!而由这个目录的 block 结果我们现在就能够知道, 当你使用『 ll / 』时,出现的目录几乎都是 1024 的倍数,为什么呢?因为每个 block 的数量都是 1K, 2K, 4K 嘛! 看一下鸟哥的环境:
由于鸟哥的根目录 /dev/hdc2 使用的 block 大小为 4K ,因此每个目录几乎都是 4K 的倍数。 其中由于 /sbin 的内容比较复杂因此占用了 3 个 block ,此外,鸟哥的系统中 /boot 为独立的 partition , 该 partition 的 block 为 1K 而已,因此该目录就仅占用 1024 bytes 的大小啰!至于奇怪的 /proc 我们在第六章就讲过该目录不占硬盘容量, 所以当然耗用的 block 就是 0 啰!
当我们在 Linux 下的 ext2 创建一个一般文件时, ext2 会分配一个 inode 与相对于该文件大小的 block 数量给该文件。例如:假设我的一个 block 为 4 Kbytes ,而我要创建一个 100 KBytes 的文件,那么 linux 将分配一个 inode 与 25 个 block 来储存该文件! 但同时请注意,由于 inode 仅有 12 个直接指向,因此还要多一个 block 来作为区块号码的记录喔!
好了,经过上面的说明你也应该要很清楚的知道 inode 本身并不记录文件名,文件名的记录是在目录的 block 当中。 因此在第六章文件与目录的权限说明中, 我们才会提到『新增/删除/更名文件名与目录的 w 权限有关』的特色!那么因为文件名是记录在目录的 block 当中, 因此当我们要读取某个文件时,就务必会经过目录的 inode 与 block ,然后才能够找到那个待读取文件的 inode 号码, 最终才会读到正确的文件的 block 内的数据。 由于目录树是由根目录开始读起,因此系统透过挂载的信息可以找到挂载点的 inode 号码(通常一个 filesystem 的最顶层 inode 号码会由 2 号开始喔!),此时就能够得到根目录的 inode 内容,并依据该 inode 读取根目录的 block 内的文件名数据,再一层一层的往下读到正确的档名。 举例来说,如果我想要读取 /etc/passwd 这个文件时,系统是如何读取的呢?
在鸟哥的系统上面与 /etc/passwd 有关的目录与文件数据如上表所示,该文件的读取流程为(假设读取者身份为 vbird 这个一般身份使用者):
另外,关于文件系统的使用效率上,当你的一个文件系统规划的很大时,例如 100GB 这么大时, 由于硬盘上面的数据总是来来去去的,所以,整个文件系统上面的文件通常无法连续写在一起(block 号码不会连续的意思), 而是填入式的将数据填入没有被使用的 block 当中。如果文件写入的 block 真的分的很散, 此时就会有所谓的文件数据离散的问题发生了。 如前所述,虽然我们的 ext2 在 inode 处已经将该文件所记录的 block 号码都记上了, 所以数据可以一次性读取,但是如果文件真的太过离散,确实还是会发生读取效率低落的问题。 因为磁盘读取头还是得要在整个文件系统中来来去去的频繁读取! 果真如此,那么可以将整个 filesystme 内的数据全部复制出来,将该 filesystem 重新格式化, 再将数据给他复制回去即可解决这个问题。 此外,如果 filesystem 真的太大了,那么当一个文件分别记录在这个文件系统的最前面与最后面的 block 号码中, 此时会造成硬盘的机械手臂移动幅度过大,也会造成数据读取效能的低落。而且读取头在搜寻整个 filesystem 时, 也会花费比较多的时间去搜寻!因此, partition 的规划并不是越大越好, 而是真的要针对您的主机用途来进行规划才行!^_^ EXT2/EXT3 文件的存取与日志式文件系统的功能 上一小节谈到的仅是读取而已,那么如果是新建一个文件或目录时,我们的 Ext2 是如何处理的呢? 这个时候就得要 block bitmap 及 inode bitmap 的帮忙了!假设我们想要新增一个文件,此时文件系统的行为是:
一般来说,我们将 inode table 与 data block 称为数据存放区域,至于其他例如 superblock、 block bitmap 与 inode bitmap 等区段就被称为 metadata (中介数据) 啰,因为 superblock, inode bitmap 及 block bitmap 的数据是经常变动的,每次新增、移除、编辑时都可能会影响到这三个部分的数据,因此才被称为中介数据的啦。
在一般正常的情况下,上述的新增动作当然可以顺利的完成。但是如果有个万一怎么办? 例如你的文件在写入文件系统时,因为不知名原因导致系统中断(例如突然的停电啊、 系统核心发生错误啊~等等的怪事发生时),所以写入的数据仅有 inode table 及 data block 而已, 最后一个同步升级中介数据的步骤并没有做完,此时就会发生 metadata 的内容与实际数据存放区产生不一致 (Inconsistent) 的情况了。 既然有不一致当然就得要克服!在早期的 Ext2 文件系统中,如果发生这个问题, 那么系统在重新启动的时候,就会藉由 Superblock 当中记录的 valid bit (是否有挂载) 与 filesystem state (clean 与否) 等状态来判断是否强制进行数据一致性的检查!若有需要检查时则以 e2fsck 这支程序来进行的。 不过,这样的检查真的是很费时~因为要针对 metadata 区域与实际数据存放区来进行比对, 呵呵~得要搜寻整个 filesystem 呢~如果你的文件系统有 100GB 以上,而且里面的文件数量又多时, 哇!系统真忙碌~而且在对 Internet 提供服务的服务器主机上面, 这样的检查真的会造成主机复原时间的拉长~真是麻烦~这也就造成后来所谓日志式文件系统的兴起了。
为了避免上述提到的文件系统不一致的情况发生,因此我们的前辈们想到一个方式, 如果在我们的 filesystem 当中规划出一个区块,该区块专门在记录写入或修订文件时的步骤, 那不就可以简化一致性检查的步骤了?也就是说:
在这样的程序当中,万一数据的纪录过程当中发生了问题,那么我们的系统只要去检查日志记录区块, 就可以知道哪个文件发生了问题,针对该问题来做一致性的检查即可,而不必针对整块 filesystem 去检查, 这样就可以达到快速修复 filesystem 的能力了!这就是日志式文件最基础的功能啰~ 那么我们的 ext2 可达到这样的功能吗?当然可以啊! 就透过 ext3 即可! ext3 是 ext2 的升级版本,并且可向下兼容 ext2 版本呢! 所以啰,目前我们才建议大家,可以直接使用 ext3 这个 filesystem 啊! 如果你还记得 dumpe2fs 输出的信息,可以发现 superblock 里面含有底下这样的信息:
看到了吧!透过 inode 8 号记录 journal 区块的 block 指向,而且具有 128MB 的容量在处理日志呢! 这样对于所谓的日志式文件系统有没有比较有概念一点呢?^_^。如果想要知道为什么 Ext3 文件系统会更适用于目前的 Linux 系统, 我们可以参考 Red Hat 公司中,首席核心开发者 Michael K. Johnson 的话:(注6)
Linux 文件系统的运行: 我们现在知道了目录树与文件系统的关系了,但是由第零章的内容我们也知道, 所有的数据都得要加载到内存后 CPU 才能够对该数据进行处理。想一想,如果你常常编辑一个好大的文件, 在编辑的过程中又频繁的要系统来写入到磁盘中,由于磁盘写入的速度要比内存慢很多, 因此你会常常耗在等待硬盘的写入/读取上。真没效率! 为了解决这个效率的问题,因此我们的 Linux 使用的方式是透过一个称为异步处理 (asynchronously) 的方式。所谓的异步处理是这样的: 当系统加载一个文件到内存后,如果该文件没有被更动过,则在内存区段的文件数据会被配置为干净(clean)的。 但如果内存中的文件数据被更改过了(例如你用 nano 去编辑过这个文件),此时该内存中的数据会被配置为脏的 (Dirty)。此时所有的动作都还在内存中运行,并没有写入到磁盘中! 系统会不定时的将内存中配置为『Dirty』的数据写回磁盘,以保持磁盘与内存数据的一致性。 你也可以利用第五章谈到的 sync命令来手动强迫写入磁盘。 我们知道内存的速度要比硬盘快的多,因此如果能够将常用的文件放置到内存当中,这不就会添加系统性能吗? 没错!是有这样的想法!因此我们 Linux 系统上面文件系统与内存有非常大的关系喔:
挂载点的意义 (mount point): 每个 filesystem 都有独立的 inode / block / superblock 等信息,这个文件系统要能够链接到目录树才能被我们使用。 将文件系统与目录树结合的动作我们称为『挂载』。 关于挂载的一些特性我们在第三章稍微提过, 重点是:挂载点一定是目录,该目录为进入该文件系统的入口。 因此并不是你有任何文件系统都能使用,必须要『挂载』到目录树的某个目录后,才能够使用该文件系统的。 举例来说,如果你是依据鸟哥的方法安装你的 CentOS 5.x 的话, 那么应该会有三个挂载点才是,分别是 /, /boot, /home 三个 (鸟哥的系统上对应的装置文件名为 /dev/hdc2, /dev/hdc1, /dev/hdc3)。 那如果观察这三个目录的 inode 号码时,我们可以发现如下的情况:
看到了吧!由于 filesystem 最顶层的目录之 inode 一般为 2 号,因此可以发现 /, /boot, /home 为三个不同的 filesystem 啰! (因为每一行的文件属性并不相同,且三个目录的挂载点也均不相同之故。) 我们在第七章一开始的路径中曾经提到根目录下的 . 与 .. 是相同的东西, 因为权限是一模一样嘛!如果使用文件系统的观点来看,同一个 filesystem 的某个 inode 只会对应到一个文件内容而已(因为一个文件占用一个 inode 之故), 因此我们可以透过判断 inode 号码来确认不同文件名是否为相同的文件喔!所以可以这样看:
上面的信息中由于挂载点均为 / ,因此三个文件 (/, /., /..) 均在同一个 filesystem 内,而这三个文件的 inode 号码均为 2 号,因此这三个档名都指向同一个 inode 号码,当然这三个文件的内容也就完全一模一样了! 也就是说,根目录的上一级 (/..) 就是他自己!这么说,看的懂了吗? ^_^ 其他 Linux 支持的文件系统与 VFS 虽然 Linux 的标准文件系统是 ext2 ,且还有添加了日志功能的 ext3 ,事实上,Linux 还有支持很多文件系统格式的, 尤其是最近这几年推出了好几种速度很快的日志式文件系统,包括 SGI 的 XFS 文件系统, 可以适用更小型文件的 Reiserfs 文件系统,以及 Windows 的 FAT 文件系统等等, 都能够被 Linux 所支持喔!常见的支持文件系统有:
想要知道你的 Linux 支持的文件系统有哪些,可以察看底下这个目录:
系统目前已加载到内存中支持的文件系统则有:
了解了我们使用的文件系统之后,再来则是要提到,那么 Linux 的核心又是如何管理这些认识的文件系统呢? 其实,整个 Linux 的系统都是透过一个名为 Virtual Filesystem Switch 的核心功能去读取 filesystem 的。 也就是说,整个 Linux 认识的 filesystem 其实都是 VFS 在进行管理,我们使用者并不需要知道每个 partition 上头的 filesystem 是什么~ VFS 会主动的帮我们做好读取的动作呢~ 假设你的 / 使用的是 /dev/hda1 ,用 ext3 ,而 /home 使用 /dev/hda2 ,用 reiserfs , 那么你取用 /home/dmtsai/.bashrc 时,有特别指定要用的什么文件系统的模块来读取吗? 应该是没有吧!这个就是 VFS 的功能啦!透过这个 VFS 的功能来管理所有的 filesystem, 省去我们需要自行配置读取文件系统的定义啊~方便很多!整个 VFS 可以约略用下图来说明: 图 1.8.1、VFS 文件系统的示意图 老实说,文件系统真的不好懂! 如果你想要对文件系统有更深入的了解,文末的相关连结(注7)务必要参考参考才好喔! 鸟哥有找了一些数据放置于这里: 有兴趣的朋友务必要前往参考参考才好! 文件系统的简单操作 稍微了解了文件系统后,再来我们得要知道如何查询整体文件系统的总容量与每个目录所占用的容量啰! 此外,前两章谈到的文件类型中尚未讲的很清楚的连结档 (Link file) 也会在这一小节当中介绍的。 磁盘与目录的容量: 现在我们知道磁盘的整体数据是在 superblock 区块中,但是每个各别文件的容量则在 inode 当中记载的。 那在文字接口底下该如何叫出这几个数据呢?底下就让我们来谈一谈这两个命令:
先来说明一下范例一所输出的结果信息为:
由于 df 主要读取的数据几乎都是针对一整个文件系统,因此读取的范围主要是在 Superblock 内的信息, 所以这个命令显示结果的速度非常的快速!在显示的结果中你需要特别留意的是那个根目录的剩余容量! 因为我们所有的数据都是由根目录衍生出来的,因此当根目录的剩余容量剩下 0 时,那你的 Linux 可能就问题很大了。
另外需要注意的是,如果使用 -a 这个参数时,系统会出现 /proc 这个挂载点,但是里面的东西都是 0 ,不要紧张! /proc 的东西都是 Linux 系统所需要加载的系统数据,而且是挂载在『内存当中』的, 所以当然没有占任何的硬盘空间啰! 至于那个 /dev/shm/ 目录,其实是利用内存虚拟出来的磁盘空间! 由于是透过内存仿真出来的磁盘,因此你在这个目录底下创建任何数据文件时,访问速度是非常快速的!(在内存内工作) 不过,也由于他是内存仿真出来的,因此这个文件系统的大小在每部主机上都不一样,而且创建的东西在下次启动时就消失了! 因为是在内存中嘛!
与 df 不一样的是,du 这个命令其实会直接到文件系统内去搜寻所有的文件数据, 所以上述第三个范例命令的运行会运行一小段时间!此外,在默认的情况下,容量的输出是以 KB 来设计的, 如果你想要知道目录占了多少 MB ,那么就使用 -m 这个参数即可啰!而, 如果你只想要知道该目录占了多少容量的话,使用 -s 就可以啦! 至于 -S 这个选项部分,由于 du 默认会将所有文件的大小均列出,因此假设你在 /etc 底下使用 du 时, 所有的文件大小,包括 /etc 底下的次目录容量也会被计算一次。然后最终的容量 (/etc) 也会加总一次, 因此很多朋友都会误会 du 分析的结果不太对劲。所以啰,如果想要列出某目录下的全部数据, 或许也可以加上 -S 的选项,减少次目录的加总喔! 实体链接与符号链接: ln 关于链接(link)数据我们第六章的Linux文件属性及Linux文件种类与扩展名当中提过一些信息, 不过当时由于尚未讲到文件系统,因此无法较完整的介绍连结档啦。不过在上一小节谈完了文件系统后, 我们可以来了解一下连结档这玩意儿了。 在 Linux 底下的连结档有两种,一种是类似 Windows 的快捷方式功能的文件,可以让你快速的链接到目标文件(或目录); 另一种则是透过文件系统的 inode 连结来产生新档名,而不是产生新文件!这种称为实体链接 (hard link)。 这两种玩意儿是完全不一样的东西呢!现在就分别来谈谈。
在前一小节当中,我们知道几件重要的信息,包括:
也就是说,其实文件名只与目录有关,但是文件内容则与 inode 有关。那么想一想, 有没有可能有多个档名对应到同一个 inode 号码呢?有的!那就是 hard link 的由来。 所以简单的说:hard link 只是在某个目录下新增一笔档名链接到某 inode 号码的关连记录而已。 举个例子来说,假设我系统有个 /root/crontab 他是 /etc/crontab 的实体链接,也就是说这两个档名连结到同一个 inode , 自然这两个文件名的所有相关信息都会一模一样(除了文件名之外)。实际的情况可以如下所示:
你可以发现两个档名都连结到 1912701 这个 inode 号码,所以您瞧瞧,是否文件的权限/属性完全一样呢? 因为这两个『档名』其实是一模一样的『文件』啦!而且你也会发现第二个字段由原本的 1 变成 2 了! 那个字段称为『连结』,这个字段的意义为:『有多少个档名链接到这个 inode 号码』的意思。 如果将读取到正确数据的方式画成示意图,就类似如下画面: 图 2.2.1、实体链接的文件读取示意图 上图的意思是,你可以透过 1 或 2 的目录之 inode 指定的 block 找到两个不同的档名,而不管使用哪个档名均可以指到 real 那个 inode 去读取到最终数据!那这样有什么好处呢?最大的好处就是『安全』!如同上图中, 如果你将任何一个『档名』删除,其实 inode 与 block 都还是存在的! 此时你可以透过另一个『档名』来读取到正确的文件数据喔!此外,不论你使用哪个『档名』来编辑, 最终的结果都会写入到相同的 inode 与 block 中,因此均能进行数据的修改哩! 一般来说,使用 hard link 配置链接文件时,磁盘的空间与 inode 的数目都不会改变! 我们还是由图 2.2.1 来看,由图中可以知道, hard link 只是在某个目录下的 block 多写入一个关连数据而已,既不会添加 inode 也不会耗用 block 数量哩!
由图 2.2.1 其实我们也能够知道,事实上 hard link 应该仅能在单一文件系统中进行的,应该是不能够跨文件系统才对! 因为图 2.2.1 就是在同一个 filesystem 上嘛!所以 hard link 是有限制的:
不能跨 Filesystem 还好理解,那不能 hard link 到目录又是怎么回事呢?这是因为如果使用 hard link 链接到目录时, 链接的数据需要连同被链接目录底下的所有数据都创建链接,举例来说,如果你要将 /etc 使用实体链接创建一个 /etc_hd 的目录时,那么在 /etc_hd 底下的所有档名同时都与 /etc 底下的檔名要创建 hard link 的,而不是仅连结到 /etc_hd 与 /etc 而已。 并且,未来如果需要在 /etc_hd 底下创建新文件时,连带的, /etc 底下的数据又得要创建一次 hard link ,因此造成环境相当大的复杂度。 所以啰,目前 hard link 对于目录暂时还是不支持的啊!
相对于 hard link , Symbolic link 可就好理解多了,基本上, Symbolic link 就是在创建一个独立的文件,而这个文件会让数据的读取指向他 link 的那个文件的档名!由于只是利用文件来做为指向的动作, 所以,当来源档被删除之后,symbolic link 的文件会『开不了』, 会一直说『无法开启某文件!』。实际上就是找不到原始『档名』而已啦! 举例来说,我们先创建一个符号链接文件链接到 /etc/crontab 去看看:
由上表的结果我们可以知道两个文件指向不同的 inode 号码,当然就是两个独立的文件存在! 而且连结档的重要内容就是他会写上目标文件的『文件名』, 你可以发现为什么上表中连结档的大小为 12 bytes 呢? 因为箭头(-->)右边的档名『/etc/crontab』总共有 12 个英文,每个英文占用 1 个 byes ,所以文件大小就是 12bytes了! 关于上述的说明,我们以如下图示来解释: 图 2.2.2、符号链接的文件读取示意图 由 1 号 inode 读取到连结档的内容仅有档名,根据档名链接到正确的目录去取得目标文件的 inode , 最终就能够读取到正确的数据了。你可以发现的是,如果目标文件(/etc/crontab)被删除了,那么整个环节就会无法继续进行下去, 所以就会发生无法透过连结档读取的问题了! 这里还是得特别留意,这个 Symbolic Link 与 Windows 的快捷方式可以给他划上等号,由 Symbolic link 所创建的文件为一个独立的新的文件,所以会占用掉 inode 与 block 喔! 由上面的说明来看,似乎 hard link 比较安全,因为即使某一个目录下的关连数据被杀掉了, 也没有关系,只要有任何一个目录下存在着关连数据,那么该文件就不会不见!举上面的例子来说,我的 /etc/crontab 与 /root/crontab 指向同一个文件,如果我删除了 /etc/crontab 这个文件,该删除的动作其实只是将 /etc 目录下关于 crontab 的关连数据拿掉而已, crontab 所在的 inode 与 block 其实都没有被变动喔! 不过由于 Hard Link 的限制太多了,包括无法做『目录』的 link , 所以在用途上面是比较受限的!反而是 Symbolic Link 的使用方面较广喔!好了, 说的天花乱坠,看你也差不多快要昏倒了!没关系,实作一下就知道怎么回事了!要制作连结档就必须要使用 ln 这个命令呢!
要注意啰!使用 ln 如果不加任何参数的话,那么就是 Hard Link 啰!如同范例二的情况,添加了 hard link 之后,可以发现使用 ls -l 时,显示的 link 那一栏属性添加了!而如果这个时候砍掉 passwd 会发生什么事情呢?passwd-hd 的内容还是会跟原来 passwd 相同,但是 passwd-so 就会找不到该文件啦! 而如果 ln 使用 -s 的参数时,就做成差不多是 Windows 底下的『快捷方式』的意思。当你修改 Linux 下的 symbolic link 文件时,则更动的其实是『原始档』, 所以不论你的这个原始档被连结到哪里去,只要你修改了连结档,原始档就跟着变啰! 以上面为例,由于你使用 -s 的参数创建一个名为 passwd-so 的文件,则你修改 passwd-so 时,其内容与 passwd 完全相同,并且,当你按下储存之后,被改变的将是 passwd 这个文件! 此外,如果你做了底下这样的连结: ln -s /bin /root/bin 那么如果你进入 /root/bin 这个目录下,『请注意呦!该目录其实是 /bin 这个目录,因为你做了连结档了!』所以,如果你进入 /root/bin 这个刚刚创建的链接目录, 并且将其中的数据杀掉时,嗯! /bin 里面的数据就通通不见了!这点请千万注意!所以赶紧利用『rm /root/bin 』 将这个连结档删除吧! 基本上, Symbolic link 的用途比较广,所以您要特别留意 symbolic link 的用法呢!未来一定还会常常用到的啦!
或许您已经发现了,那就是,当我们以 hard link 进行『文件的连结』时,可以发现,在 ls -l 所显示的第二字段会添加一才对,那么请教,如果创建目录时,他默认的 link 数量会是多少? 让我们来想一想,一个『空目录』里面至少会存在些什么?呵呵!就是存在 . 与 .. 这两个目录啊! 那么,当我们创建一个新目录名称为 /tmp/testing 时,基本上会有三个东西,那就是:
而其中 /tmp/testing 与 /tmp/testing/. 其实是一样的!都代表该目录啊~而 /tmp/testing/.. 则代表 /tmp 这个目录,所以说,当我们创建一个新的目录时, 『新的目录的 link 数为 2 ,而上一级目录的 link 数则会添加 1 』 不信的话,我们来作个测试看看:
瞧!原本的所谓上一级目录 /tmp 的 link 数量由 5 添加为 6 ,至于新目录 /tmp/testing 则为 2 ,这样可以理解目录的 link 数量的意义了吗? ^_^ 磁盘的分割、格式化、检验与挂载: 对于一个系统管理者( root )而言,磁盘的的管理是相当重要的一环,尤其近来硬盘已经渐渐的被当成是消耗品了 ..... 如果我们想要在系统里面新增一颗硬盘时,应该有哪些动作需要做的呢:
当然啰,在上述的过程当中,还有很多需要考虑的,例如磁盘分区槽 (partition) 需要定多大? 是否需要加入 journal 的功能?inode 与 block 的数量应该如何规划等等的问题。但是这些问题的决定, 都需要与你的主机用途来加以考虑的~所以,在这个小节里面,鸟哥仅会介绍几个动作而已, 更详细的配置值,则需要以你未来的经验来参考啰! 磁盘分区: fdisk
由于每个人的环境都不一样,因此每部主机的磁盘数量也不相同。所以你可以先使用 df 这个命令找出可用磁盘文件名, 然后再用 fdisk 来查阅。在你进入 fdisk 这支程序的工作画面后,如果您的硬盘太大的话(通常指磁柱数量多于 1024 以上),就会出现如上信息。这个信息仅是在告知你,因为某些旧版的软件与操作系统并无法支持大于 1024 磁柱 (cylinter) 后的扇区使用,不过我们新版的 Linux 是没问题啦!底下继续来看看 fdisk 内如何操作相关动作吧!
老实说,使用 fdisk 这支程序是完全不需要背命令的!如同上面的表格中,你只要按下 m 就能够看到所有的动作! 比较重要的动作在上面已经用底线画出来了,你可以参考看看。其中比较不一样的是『q 与 w』这两个玩意儿! 不管你进行了什么动作,只要离开 fdisk 时按下『q』,那么所有的动作『都不会生效!』相反的, 按下『w』就是动作生效的意思。所以,你可以随便玩 fdisk ,只要离开时按下的是『q』即可。 ^_^! 好了,先来看看分割表信息吧!
使用『 p 』可以列出目前这颗磁盘的分割表信息,这个信息的上半部在显示整体磁盘的状态。 以鸟哥这颗磁盘为例,这个磁盘共有 41.1GB 左右的容量,共有 5005 个磁柱,每个磁柱透过 255 个磁头在管理读写, 每个磁头管理 63 个扇区,而每个扇区的大小均为 512bytes ,因此每个磁柱为『 255*63*512 = 16065*512 = 8225280bytes 』。 下半部的分割表信息主要在列出每个分割槽的个别信息项目。每个项目的意义为:
从上表我们可以发现几件事情:
fdisk 还可以直接秀出系统内的所有 partition 喔!举例来说,鸟哥刚刚插入一个 U盘 磁盘到这部 Linux 系统中, 那该如何观察 (1)这个磁盘的代号与 (2)这个磁盘的分割槽呢?
由上表的信息我们可以看到我有两颗磁盘,磁盘文件名为『/dev/hdc 与 /dev/sda』,/dev/hdc 已经在上面谈过了, 至于 /dev/sda 则有 8GB 左右的容量,且全部的磁柱都已经分割给 /dev/sda1 ,该文件系统应该为 Windows 的 FAT 文件系统。这样很容易查阅到分割方面的信息吧! 这个 fdisk 只有 root 才能运行,此外,请注意, 使用的『装置文件名』请不要加上数字,因为 partition 是针对『整个硬盘装置』而不是某个 partition 呢!所以运行『 fdisk /dev/hdc1 』 就会发生错误啦!要使用 fdisk /dev/hdc 才对!那么我们知道可以利用 fdisk 来查阅硬盘的 partition 信息外,底下再来说一说进入 fdisk 之后的几个常做的工作!
如果你是按照鸟哥建议的方式去安装你的 CentOS ,那么你的磁盘应该会预留一块容量来做练习的。 实际练习新增硬盘之前,我们先来玩一玩恐怖的删除好了~如果想要测试一下如何将你的 /dev/hdc 全部的分割槽删除,应该怎么做?
新增磁盘分区槽有好多种情况,因为新增 Primary / Extended / Logical 的显示结果都不太相同。 底下我们先将 /dev/hdc 全部删除成为干净未分割的磁盘,然后依序新增给大家瞧瞧!
上面的练习非常重要!您得要自行练习一下比较好!注意,不要按下 w 喔!会让你的系统损毁的! 由上面的一连串练习中,最重要的地方其实就在于创建分割槽的形式( primary/extended/logical )以及分割槽的大小了!一般来说创建分割槽的形式会有底下的数种状况:
如上的练习中,最终写入分割表后竟然会让核心无法捉到分割表信息!此时你可以直接使用 reboot 来处理, 也可以使用 GNU 推出的工具程序来处置,那就是 partprobe 这个命令。这个命令的运行很简单, 他仅是告知核心必须要读取新的分割表而已,因此并不会在屏幕上出现任何信息才是! 这样一来,我们就不需要 reboot 啰!
以 root 的身份进行硬盘的 partition 时,最好是在单人维护模式底下比较安全一些, 此外,在进行 fdisk 的时候,如果该硬盘某个 partition 还在使用当中, 那么很有可能系统核心会无法重载硬盘的 partition table ,解决的方法就是将该使用中的 partition 给他卸除,然后再重新进入 fdisk 一遍,重新写入 partition table ,那么就可以成功啰!
另外在实作过程中请特别注意,因为 SATA 硬盘最多能够支持到 15 号的分割槽, IDE 则可以支持到 63 号。 但目前大家常见的系统都是 SATA 磁盘,因此在练习的时候千万不要让你的分割槽超过 15 号! 否则即使你还有剩余的磁柱容量,但还是会无法继续进行分割的喔! 另外需要特别留意的是,fdisk 没有办法处理大于 2TB 以上的磁盘分区槽! 这个问题比较严重!因为虽然 Ext3 文件系统已经支持达到 16TB 以上的磁盘,但是分割命令却无法支持。 时至今日(2009)所有的硬件价格大跌,硬盘也已经出到单颗 1TB 之谱,若加上磁盘阵列 (RAID) , 高于 2TB 的磁盘系统应该会很常见!此时你就得使用 parted 这个命令了!我们会在本章最后谈一谈这个命令的用法。 磁盘格式化 分割完毕后自然就是要进行文件系统的格式化啰!格式化的命令非常的简单,那就是『make filesystem, mkfs』 这个命令啦!这个命令其实是个综合的命令,他会去呼叫正确的文件系统格式化工具软件! 不啰唆,让我们来瞧瞧吧!
mkfs 其实是个综合命令而已,事实上如同上表所示,当我们使用『 mkfs -t ext3 ...』时, 系统会去呼叫 mkfs.ext3 这个命令来进行格式化的动作啦!若如同上表所展现的结果, 那么鸟哥这个系统支持的文件系统格式化工具有『cramfs, ext2, ext3, msdoc, vfat』等, 而最常用的应该是 ext3, vfat 两种啦! vfat 可以用在 Windows/Linux 共享的 U盘 闪盘啰。
在格式化为 Ext3 的范例中,我们可以发现结果里面含有非常多的信息,由于我们没有详细指定文件系统的细部项目, 因此系统会使用默认值来进行格式化。其中比较重要的部分为:文件系统的标头(Label)、Block的大小以及 inode 的数量。 如果你要指定这些东西,就得要了解一下 Ext2/Ext3 的公用程序,亦即 mke2fs 这个命令啰!
mke2fs 是一个很详细但是很麻烦的命令!因为里面的细部配置太多了!现在我们进行如下的假设:
开始格式化 /dev/hdc6 结果会变成如下所示:
其实 mke2fs 所使用的各项选项/参数也可以用在『 mkfs -t ext3 ... 』后面,因为最终使用的公用程序是相同的啦! 特别要注意的是 -b, -i 及 -j 这几个选项,尤其是 -j 这个选项,当没有指定 -j 的时候, mke2fs 使用 ext2 为格式化文件格式,若加入 -j 时,则格式化为 ext3 这个 Journaling 的 filesystem 呦! 老实说,如果没有特殊需求的话,使用『 mkfs -t ext3....』不但容易记忆,而且就非常好用啰! 磁盘检验: fsck, badblocks 由于系统在运行时谁也说不准啥时硬件或者是电源会有问题,所以『死机』可能是难免的情况(不管是硬件还是软件)。 现在我们知道文件系统运行时会有硬盘与内存数据异步的状况发生,因此莫名其妙的死机非常可能导致文件系统的错乱。 问题来啦,如果文件系统真的发生错乱的话,那该如何是好?就...挽救啊!此时那个好用的 filesystem check, fsck 就得拿来仔细瞧瞧啰。
这是用来检查与修正文件系统错误的命令。注意:通常只有身为 root 且你的文件系统有问题的时候才使用这个命令,否则在正常状况下使用此一命令, 可能会造成对系统的危害!通常使用这个命令的场合都是在系统出现极大的问题,导致你在 Linux 启动的时候得进入单人单机模式下进行维护的行为时,才必须使用此一命令! 另外,如果你怀疑刚刚格式化成功的硬盘有问题的时后,也可以使用 fsck 来检查一硬盘呦!其实就有点像是 Windows 的 scandisk 啦!此外,由于 fsck 在扫瞄硬盘的时候,可能会造成部分 filesystem 的损坏,所以『运行 fsck 时, 被检查的 partition 务必不可挂载到系统上!亦即是需要在卸除的状态喔!』 不知道你还记不记得第六章的目录配置中我们提过, ext2/ext3 文件系统的最顶层(就是挂载点那个目录底下)会存在一个『lost+found』的目录吧! 该目录就是在当你使用 fsck 检查文件系统后,若出现问题时,有问题的数据会被放置到这个目录中喔! 所以理论上这个目录不应该会有任何数据,若系统自动产生数据在里面,那...你就得特别注意你的文件系统啰! 另外,我们的系统实际运行的 fsck 命令,其实是呼叫 e2fsck 这个软件啦!可以 man e2fsck 找到更多的选项辅助喔!
刚刚谈到的 fsck 是用来检验文件系统是否出错,至于 badblocks 则是用来检查硬盘或软盘扇区有没有坏轨的命令! 由于这个命令其实可以透过『 mke2fs -c 装置文件名 』在进行格式化的时候处理磁盘表面的读取测试, 因此目前大多不使用这个命令啰! 磁盘挂载与卸除 我们在本章一开始时的挂载点的意义当中提过挂载点是目录, 而这个目录是进入磁盘分区槽(其实是文件系统啦!)的入口就是了。不过要进行挂载前,你最好先确定几件事:
尤其是上述的后两点!如果你要用来挂载的目录里面并不是空的,那么挂载了文件系统之后,原目录下的东西就会暂时的消失。 举个例子来说,假设你的 /home 原本与根目录 (/) 在同一个文件系统中,底下原本就有 /home/test 与 /home/vbird 两个目录。然后你想要加入新的硬盘,并且直接挂载 /home 底下,那么当你挂载上新的分割槽时,则 /home 目录显示的是新分割槽内的数据,至于原先的 test 与 vbird 这两个目录就会暂时的被隐藏掉了!注意喔!并不是被覆盖掉, 而是暂时的隐藏了起来,等到新分割槽被卸除之后,则 /home 原本的内容就会再次的跑出来啦! 而要将文件系统挂载到我们的 Linux 系统上,就要使用 mount 这个命令啦! 不过,这个命令真的是博大精深~粉难啦!我们学简单一点啊~ ^_^
会不会觉得光是看这个命令的细部选项就快要昏倒了?如果有兴趣的话看一下 man mount ,那才会真的昏倒的。 事实上 mount 是个很万用的命令,他可以挂载 ext3/vfat/nfs 等文件系统,由于每种文件系统的数据并不相同, 想当然尔,详细的参数与选项自然也就不相同啦!不过实际应用时却简单的会让你想笑呢! 看看底下的几个简单范例先!
瞎密?竟然这么简单!利用『mount 装置文件名 挂载点』就能够顺利的挂载了!真是方便啊! 为什么可以这么方便呢(甚至不需要使用 -t 这个选项)?由于文件系统几乎都有 superblock , 我们的 Linux 可以透过分析 superblock 搭配 Linux 自己的驱动程序去测试挂载, 如果成功的套和了,就立刻自动的使用该类型的文件系统挂载起来啊! 那么系统有没有指定哪些类型的 filesystem 才需要进行上述的挂载测试呢? 主要是参考底下这两个文件:
那我怎么知道我的 Linux 有没有相关文件系统类型的驱动程序呢?我们 Linux 支持的文件系统之驱动程序都写在如下的目录中:
例如 vfat 的驱动程序就写在『/lib/modules/$(uname -r)/kernel/fs/vfat/』这个目录下啦! 简单的测试挂载后,接下来让我们检查看看目前已挂载的文件系统状况吧!
这个命令输出的结果可以让我们看到非常多信息,以 /dev/hdc2 这个装置来说好了(上面表格的第一行), 他的意义是:『/dev/hdc2 是挂载到 / 目录,文件系统类型为 ext3 ,且挂载为可擦写 (rw) ,另外,这个 filesystem 有标头,名字(label)为 /1』 这样,你会解释上述表格中的最后一行输出结果了吗?自己解释一下先。^_^。 接下来请拿出你的 CentOS DVD 放入光驱中,并拿 FAT 格式的 U盘 闪盘(不要用 NTFS 的)插入 U盘 插槽中,我们来测试挂载一下!
光驱一挂载之后就无法退出光盘片了!除非你将他卸除才能够退出! 从上面的数据你也可以发现,因为是光盘嘛!所以磁盘使用率达到 100% ,因为你无法直接写入任何数据到光盘当中ㄇㄟ! 另外,其实 /dev/cdrom 是个链接文件,正确的磁盘文件名得要看你的光驱是什么连接接口的环境。 以鸟哥为例,我的光驱接在 /dev/hdd,所以正确的挂载应该是『mount /dev/hdd /media/cdrom』比较正确喔!
软盘的格式化可以直接使用 mkfs 即可。但是软盘也是可以格式化成为 ext3 或 vfat 格式的。 挂载的时候我们同样的使用系统自动测试挂载即可!真是粉简单!如果你有软盘片的话(很少人有了吧?), 请先放置到软盘驱动器当中啰!底下来测试看看(软盘片请勿放置任何数据,且将写保护打开!)。
与光驱不同的是,你挂载了软盘后竟然还是可以退出软盘喔!不过,如此一来你的文件系统将会有莫名奇妙的问题发生! 整个 Linux 最重要的就是文件系统,而文件系统是直接挂载到目录树上头, 几乎任何命令都会或多或少使用到目录树的数据,因此你当然不可以随意的将光盘/软盘拿出来! 所以,软盘也请卸除之后再退出!很重要的一点!
请拿出你的闪盘并插入 Linux 主机的 U盘 槽中!注意,你的这个闪盘不能够是 NTFS 的文件系统喔! 接下来让我们测试测试吧!
如果带有中文文件名的数据,那么可以在挂载时指定一下挂载文件系统所使用的语系数据。 在 man mount 找到 vfat 文件格式当中可以使用 iocharset 来指定语系,而中文语系是 cp950 , 所以也就有了上述的挂载命令项目啰。 万一你使用的是随身硬盘,也就是利用笔记型计算机所做出来的U盘磁盘时,通常这样的硬盘都使用 NTFS 格式的~ 怎办?没关系,可以参考底下这个网站:(注8)
将她们提供的驱动程序捉下来并且安装之后,就能够使用 NTFS 的文件系统了! 只是由于文件系统与 Linux 核心有很大的关系,因此以后如果你的 Linux 系统有升级 (update) 时, 你就得要重新下载一次相对应的驱动程序版本喔!
整个目录树最重要的地方就是根目录了,所以根目录根本就不能够被卸除的!问题是,如果你的挂载参数要改变, 或者是根目录出现『只读』状态时,如何重新挂载呢?最可能的处理方式就是重新启动 (reboot)! 不过你也可以这样做:
重点是那个『 -o remount,xx 』的选项与参数!请注意,要重新挂载 (remount) 时, 这是个非常重要的机制!尤其是当你进入单人维护模式时,你的根目录常会被系统挂载为只读,这个时候这个命令就太重要了! 另外,我们也可以利用 mount 来将某个目录挂载到另外一个目录去喔!这并不是挂载文件系统,而是额外挂载某个目录的方法! 虽然底下的方法也可以使用 symbolic link 来连结,不过在某些不支持符号链接的程序运行中,还是得要透过这样的方法才行。
看起来,其实两者连结到同一个 inode 嘛! ^_^ 没错啦!透过这个 mount --bind 的功能, 您可以将某个目录挂载到其他目录去喔!而并不是整块 filesystem 的啦!所以从此进入 /mnt/home 就是进入 /home 的意思喔!
就是直接将已挂载的文件系统给他卸除即是!卸除之后,可以使用 df 或 mount -l 看看是否还存在目录树中? 卸除的方式,可以下达装置文件名或挂载点,均可接受啦!底下的范例做看看吧!
由于通通卸除了,此时你才可以退出光盘片、软盘片、U盘闪盘等设备喔!如果你遇到这样的情况:
由于你目前正在 /media/cdrom/ 的目录内,也就是说其实『你正在使用该文件系统』的意思! 所以自然无法卸除这个装置!那该如何是好?就『离开该文件系统的挂载点』即可。以上述的案例来说, 你可以使用『 cd / 』回到根目录,就能够卸除 /media/cdrom 啰!简单吧!
除了磁盘的装置文件名之外,其实我们可以使用文件系统的标头(label)名称来挂载喔! 举例来说,我们刚刚卸除的 /dev/hdc6 标头名称是『vbird_logical』,你也可以使用 dumpe2fs 这个命令来查询一下啦!然后就这样做即可:
这种挂载的方法有一个很大的好处:『系统不必知道该文件系统所在的接口与磁盘文件名!』 更详细的说明我们会在下一小节当中的 e2label 介绍的! 磁盘参数修订 某些时刻,你可能会希望修改一下目前文件系统的一些相关信息,举例来说,你可能要修改 Label name , 或者是 journal 的参数,或者是其他硬盘运行时的相关参数 (例如 DMA 启动与否~)。 这个时候,就得需要底下这些相关的命令功能啰~
还记得我们说过,在 Linux 底下所有的装置都以文件来代表吧!但是那个文件如何代表该装置呢? 很简单!就是透过文件的 major 与 minor 数值来替代的~所以,那个 major 与 minor 数值是有特殊意义的,不是随意配置的喔!举例来说,在鸟哥的这个测试机当中, 那个用到的磁盘 /dev/hdc 的相关装置代码如下:
上表当中 22 为主要装置代码 (Major) 而 0~6 则为次要装置代码 (Minor)。 我们的 Linux 核心认识的装置数据就是透过这两个数值来决定的!举例来说,常见的硬盘文件名 /dev/hda 与 /dev/sda 装置代码如下所示:
如果你想要知道更多核心支持的硬件装置代码 (major, minor) 请参考官网的连结(注9): 基本上,Linux 核心 2.6 版以后,硬件文件名已经都可以被系统自动的实时产生了,我们根本不需要手动创建装置文件。 不过某些情况底下我们可能还是得要手动处理装置文件的,例如在某些服务被关到特定目录下时(chroot), 就需要这样做了。此时这个 mknod 就得要知道如何操作才行!
我们在 mkfs 命令介绍时有谈到配置文件系统标头 (Label) 的方法。 那如果格式化完毕后想要修改标头呢?就用这个 e2label 来修改了。那什么是 Label 呢? 我们拿你曾用过的 Windows 系统来说明。当你打开『文件总管』时,C/D等槽不是都会有个名称吗? 那就是 label (如果没有配置名称,就会显示『本机磁盘驱动器』的字样) 这个东西除了有趣且可以让你知道磁盘的内容是啥玩意儿之外,也会被使用到一些配置文件案当中! 举例来说,刚刚我们聊到的磁盘的挂载时,不就有用到 Label name 来进行挂载吗? 目前 CentOS 的配置文件,也就是那个 /etc/fstab 文件的配置都默认使用 Label name 呢! 那这样做有什么好处与缺点呢?
鸟哥一直是个比较『硬派』作风,所以我还是比较喜欢直接利用磁盘文件名来挂载啦! 不过,如果没有特殊需求的话,那么利用 Label 来挂载也成! 但是你就不可以随意修改 Label 的名称了!
这个命令的功能其实很广泛啦~上面鸟哥仅列出很简单的一些参数而已, 更多的用法请自行参考 man tune2fs 。比较有趣的是,如果你的某个 partition 原本是 ext2 的文件系统,如果想要将他升级成为 ext3 文件系统的话,利用 tune2fs 就可以很简单的转换过来啰~
如果你的硬盘是 IDE 接口的,那么这个命令可以帮助你配置一些进阶参数!如果你是使用 SATA 接口的, 那么这个命令就没有多大用途了!另外,目前的 Linux 系统都已经稍微优化过,所以这个命令最多是用来测试效能啦! 而且建议你不要随便调整硬盘参数,文件系统容易出问题喔!除非你真的知道你调整的数据是啥!
如果你是使用 SATA 硬盘的话,这个命令唯一可以做的,就是最后面那个测试的功能而已啰! 虽然这样的测试不是很准确,至少是一个可以比较的基准。鸟哥在我的 cluster 机器上面测试的 SATA (/dev/sda) 与 RAID (/dev/sdb) 结果如下,可以提供给你参考看看。
配置启动挂载: 手动处理 mount 不是很人性化,我们总是需要让系统『自动』在启动时进行挂载的!本小节就是在谈这玩意儿! 另外,从 FTP 服务器捉下来的映像档能否不用刻录就可以读取内容?我们也需要谈谈先! 启动挂载 /etc/fstab 及 /etc/mtab 刚刚上面说了许多,那么可不可以在启动的时候就将我要的文件系统都挂好呢?这样我就不需要每次进入 Linux 系统都还要在挂载一次呀!当然可以啰!那就直接到 /etc/fstab 里面去修修就行啰!不过,在开始说明前,这里要先跟大家说一说系统挂载的一些限制:
让我们直接查阅一下 /etc/fstab 这个文件的内容吧!
其实 /etc/fstab (filesystem table) 就是将我们利用 mount 命令进行挂载时, 将所有的选项与参数写入到这个文件中就是了。除此之外, /etc/fstab 还加入了 dump 这个备份用命令的支持! 与启动时是否进行文件系统检验 fsck 等命令有关。 这个文件的内容共有六个字段,这六个字段非常的重要!你『一定要背起来』才好! 各个字段的详细数据如下:
这个字段请填入文件系统的装置文件名。但是由上面表格的默认值我们知道系统默认使用的是 Label 名称! 在鸟哥的这个测试系统中 /dev/hdc2 标头名称为 /1,所以上述表格中的『LABEL=/1』也可以被取代成为『/dev/hdc2』的意思。 至于Label可以使用 dumpe2fs 命令来查阅的。
就是挂载点啊!挂载点是什么?一定是目录啊~要知道啊!
在手动挂载时可以让系统自动测试挂载,但在这个文件当中我们必须要手动写入文件系统才行! 包括 ext3, reiserfs, nfs, vfat 等等。
记不记得我们在 mount 这个命令中谈到很多特殊的文件系统参数? 还有我们使用过的『-o iocharset=cp950』?这些特殊的参数就是写入在这个字段啦! 虽然之前在 mount 已经提过一次,这里我们利用表格的方式再汇整一下:
dump 是一个用来做为备份的命令(我们会在第二十五章备份策略中谈到这个命令), 我们可以透过 fstab 指定哪个文件系统必须要进行 dump 备份! 0 代表不要做 dump 备份, 1 代表要每天进行 dump 的动作。 2 也代表其他不定日期的 dump 备份动作, 通常这个数值不是 0 就是 1 啦!
启动的过程中,系统默认会以 fsck 检验我们的 filesystem 是否完整 (clean)。 不过,某些 filesystem 是不需要检验的,例如内存置换空间 (swap) ,或者是特殊文件系统例如 /proc 与 /sys 等等。所以,在这个字段中,我们可以配置是否要以 fsck 检验该 filesystem 喔。 0 是不要检验, 1 表示最早检验(一般只有根目录会配置为 1), 2 也是要检验,不过 1 会比较早被检验啦! 一般来说,根目录配置为 1 ,其他的要检验的 filesystem 都配置为 2 就好了。
/etc/fstab 是启动时的配置文件,不过,实际 filesystem 的挂载是记录到 /etc/mtab 与 /proc/mounts 这两个文件当中的。每次我们在更动 filesystem 的挂载时,也会同时更动这两个文件喔!但是,万一发生您在 /etc/fstab 输入的数据错误,导致无法顺利启动成功,而进入单人维护模式当中,那时候的 / 可是 read only 的状态,当然您就无法修改 /etc/fstab ,也无法升级 /etc/mtab 啰~那怎么办? 没关系,可以利用底下这一招:
特殊装置 loop 挂载 (映象档不刻录就挂载使用)
想象一下如果今天我们从国家高速网络中心(http://ftp.twaren.net)或者是义守大学(http://ftp.isu.edu.tw)下载了 Linux 或者是其他所需光盘/DVD的映象文件后, 难道一定需要刻录成为光盘才能够使用该文件里面的数据吗?当然不是啦!我们可以透过 loop 装置来挂载的! 那要如何挂载呢?鸟哥将整个 CentOS 5.2 的 DVD 映象档捉到测试机上面,然后利用这个文件来挂载给大家参考看看啰!
非常方便吧!如此一来我们不需要将这个文件刻录成为光盘或者是 DVD 就能够读取内部的数据了! 换句话说,你也可以在这个文件内『动手脚』去修改文件的!这也是为什么很多映象档提供后,还得要提供验证码 (MD5) 给使用者确认该映象档没有问题!
想一想,既然能够挂载 DVD 的映象档,那么我能不能制作出一个大文件,然后将这个文件格式化后挂载呢? 好问题!这是个有趣的动作!而且还能够帮助我们解决很多系统的分割不良的情况呢!举例来说,如果当初在分割时, 你只有分割出一个根目录,假设你已经没有多余的容量可以进行额外的分割的!偏偏根目录的容量还很大! 此时你就能够制作出一个大文件,然后将这个文件挂载!如此一来感觉上你就多了一个分割槽啰! 用途非常的广泛啦! 底下我们在 /home 下创建一个 512MB 左右的大文件,然后将这个大文件格式化并且实际挂载来玩一玩! 这样你会比较清楚鸟哥在讲啥!
透过这个简单的方法,感觉上你就可以在原本的分割槽在不更动原有的环境下制作出你想要的分割槽就是了! 这东西很好用的!尤其是想要玩 Linux 上面的『虚拟机』的话, 也就是以一部 Linux 主机再切割成为数个独立的主机系统时,类似 VMware 这类的软件, 在 Linux 上使用 xen 这个软件,他就可以配合这种 loop device 的文件类型来进行根目录的挂载, 真的非常有用的喔! ^_^ 内存置换空间(swap)之建置 还记得在安装 Linux 之前大家常常会告诉你的话吧!就是安装时一定需要的两个 partition 啰! 一个是根目录,另外一个就是 swap(内存置换空间)。关于内存置换空间的解释在第四章安装 Linux 内的磁盘分区时有约略提过, swap 的功能就是在应付物理内存不足的情况下所造成的内存延伸记录的功能。 一般来说,如果硬件的配备足够的话,那么 swap 应该不会被我们的系统所使用到, swap 会被利用到的时刻通常就是物理内存不足的情况了。从第零章的计算器概论当中,我们知道 CPU 所读取的数据都来自于内存, 那当内存不足的时候,为了让后续的程序可以顺利的运行,因此在内存中暂不使用的程序与数据就会被挪到 swap 中了。 此时内存就会空出来给需要运行的程序加载。由于 swap 是用硬盘来暂时放置内存中的信息, 所以用到 swap 时,你的主机硬盘灯就会开始闪个不停啊! 虽然目前(2009)主机的内存都很大,至少都有 1GB 以上啰!因此在个人使用上你不要配置 swap 应该也没有什么太大的问题。 不过服务器可就不这么想了~由于你不会知道何时会有大量来自网络的要求,因此你最好能够预留一些 swap 来缓冲一下系统的内存用量! 至少达到『备而不用』的地步啊! 现在想象一个情况,你已经将系统创建起来了,此时却才发现你没有建置 swap ~那该如何是好呢? 透过本章上面谈到的方法,你可以使用如下的方式来创建你的 swap 啰!
不啰唆,就立刻来处理处理吧! 使用实体分割槽建置swap 创建 swap 分割槽的方式也是非常的简单的!透过底下几个步骤就搞定啰:
不啰唆,立刻来实作看看!既然我们还有多余的磁盘容量可以分割,那么让我们继续分割出 256MB 的磁盘分区槽吧! 然后将这个磁盘分区槽做成 swap 吧!
使用文件建置swap 如果是在实体分割槽无法支持的环境下,此时前一小节提到的 loop 装置建置方法就派的上用场啦! 与实体分割槽不一样的只是利用 dd 去建置一个大文件而已。多说无益,我们就再透过文件建置的方法创建一个 128 MB 的内存置换空间吧!
swap使用上的限制 说实话,swap 在目前的壁纸计算机来讲,存在的意义已经不大了!这是因为目前的 x86 主机所含的内存实在都太大了 (一般入门级至少也都有 512MB 了),所以,我们的 Linux 系统大概都用不到 swap 这个玩意儿的。不过, 如果是针对服务器或者是工作站这些常年上线的系统来说的话,那么,无论如何,swap 还是需要创建的。 因为 swap 主要的功能是当物理内存不够时,则某些在内存当中所占的程序会暂时被移动到 swap 当中,让物理内存可以被需要的程序来使用。另外,如果你的主机支持电源管理模式, 也就是说,你的 Linux 主机系统可以进入『休眠』模式的话,那么, 运行当中的程序状态则会被纪录到 swap 去,以作为『唤醒』主机的状态依据! 另外,有某些程序在运行时,本来就会利用 swap 的特性来存放一些数据段, 所以, swap 来是需要创建的!只是不需要太大! 不过, swap 在被创建时,是有限制的喔!
文件系统的特殊观察与操作 文件系统实在是非常有趣的东西,鸟哥学了好几年还是很多东西不很懂呢! 在学习的过程中很多朋友在讨论区都有提供一些想法!这些想法将他归纳起来有底下几点可以参考的数据呢! boot sector 与 superblock 的关系 在过去非常多的文章都写到启动管理程序是安装到 superblock 内的,但是我们由官方的 How to 文件知道,图解(图 1.3.1)的结果是将可安装启动信息的 boot sector (启动扇区) 独立出来,并非放置到 superblock 当中的! 那么也就是说过去的文章写错了?这其实还是可以讨论讨论的! 经过一些搜寻,鸟哥找到几篇文章(非官方文件)的说明,大多是网友分析的结果啦!如下所示:(注10)
这几篇文章有几个重点,归纳一下如下:
分析上述两点我们知道 boot sector 应该会占有 1024 bytes 的大小吧!但是整个文件系统主要是依据 block 大小来决定的啊! 因此要讨论 boot sector 与 superblock 的关系时,不得不将 block 的大小拿出来讨论讨论喔!
如果 block 大小刚好是 1024 的话,那么 boot sector 与 superblock 各会占用掉一个 block , 所以整个文件系统图示就会如同图 1.3.1 所显示的那样,boot sector 是独立于 superblock 外面的! 由于鸟哥在基础篇安装的环境中有个 /boot 的独立文件系统在 /dev/hdc1 中,使用 dumpe2fs 观察的结果有点像底下这样(如果你是按照鸟哥的教学安装你的 CentOS 时,可以发现相同的情况喔!):
由上表我们可以确实的发现 0 号 block 是保留下来的,那就是留给 boot sector 用的啰! 所以整个分割槽的文件系统分区有点像底下这样的图示: 图 6.1.1、1K block 的 boot sector 示意图
如果 block 大于 1024 的话,那么 superblock 将会在 0 号!我们撷取本章一开始介绍 dumpe2fs 时的内容来说明一下好了!
我们可以发现 superblock 就在第一个 block (第 0 号) 上头!但是 superblock 其实就只有 1024bytes 嘛! 为了怕浪费更多空间,因此第一个 block 内就含有 boot sector 与 superblock 两者 !举上头的表格来说,因为每个 block 占有 4K ,因此在第一个 block 内 superblock 仅占有 1024-2047 ( 由 0 号起算的话)之间的咚咚,至于 2048bytes 以后的空间就真的是保留啦!而 0-1023 就保留给 boot sector 来使用。 图 6.1.2、4K block 的 boot sector 示意图 因为上述的情况,如果在比较大的 block 尺寸(size)中,我们可能可以说你能够将启动管理程序安装到 superblock 所在的 block 号码中!就是上表的 0 号啰!但事实上还是安装到 boot sector 的保留区域中啦!所以说, 以前的文章说启动管理程序可以安装到 superblock 内也不能算全错~但比较正确的说法,应该是安装到该 filesystem 最前面的 1024 bytes 内的区域,就是 boot sector 这样比较好! 磁盘空间之浪费问题 我们在前面的 block 介绍中谈到了一个 block 只能放置一个文件, 因此太多小文件将会浪费非常多的磁盘容量。但你有没有注意到,整个文件系统中包括 superblock, inode table 与其他中介数据等其实都会浪费磁盘容量喔!所以当我们在 /dev/hdc6 创建起 ext3 文件系统时, 一挂载就立刻有很多容量被用掉了! 另外,不知道你有没有发现到,当你使用 ls -l 去查询某个目录下的数据时,第一行都会出现一个『total』的字样! 那是啥东西?其实那就是该目录下的所有数据所耗用的实际 block 数量 * block 大小的值。 我们可以透过 ll -s 来观察看看上述的意义:
从上面的特殊字体部分,那就是每个文件所使用掉 block 的容量!举例来说,那个 crontab 虽然仅有 255bytes , 不过他却占用了两个 block (每个 block 为 4K),将所有的 block 加总就得到 104Kbytes 那个数值了。 如果计算每个文件实际容量的加总结果,其实只有 56.5K 而已~所以啰,这样就耗费掉好多容量了! 如果想要查询某个目录所耗用的所有容量时,那就使用 du 吧!不过 du 如果加上 -s 这个选项时, 还可以依据不同的规范去找出文件系统所消耗的容量喔!举例来说,我们就来看看 /etc/ 这个目录的容量状态吧!
使用 bytes 去分析时,发现到实际的数据占用约 103.3Mbytes,但是使用 block 去测试,就发现其实耗用了 118Mbytes, 此时文件系统就耗费了约 15Mbytes 啰!这样看的懂我们在讲的数据了吧? 利用 GNU 的 parted 进行分割行为 虽然你可以使用 fdisk 很快速的将你的分割槽切割妥当,不过 fdisk 却无法支持到高于 2TB 以上的分割槽! 此时就得需要 parted 来处理了。不要觉得 2TB 你用不着! 2009 年的现在已经有单颗硬盘高达 2TB 的容量了! 如果再搭配主机系统有内建磁盘阵列装置,要使用数个 TB 的单一磁盘装置也不是不可能的! 所以,还是得要学一下这个重要的工具! parted ! parted 可以直接在一行命令列就完成分割,是一个非常好用的命令!他的语法有点像这样:
上面是最简单的 parted 命令功能简介,你可以使用『 man parted 』,或者是『 parted /dev/hdc help mkpart 』去查询更详细的数据。比较有趣的地方在于分割表的输出。我们将上述的分割表示意拆成六部分来说明:
接下来我们尝试来创建一个全新的分割槽吧!因为我们仅剩下逻辑分割槽可用,所以等一下底下我们选择的会是 logical 的分割类型喔!
关于 parted 的介绍我们就到这里啦!除非你有使用到大于 2TB 以上的磁盘, 否则请爱用 fdisk 这个程序来进行分割喔!拜托拜托! |