superblock损坏_black-box

首先，Superblock, Inode, Dentry 和 File 都属于元数据(Metadata)，根据维基百科中的解释，所谓元数据，就是描述数据的数据（data about data），主要是描述数据属性（property）的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。Linux/Unix 文件系统的元数据以多级结构保存。

• superblock：记录此filesystem 的整体信息，包括inode/block的总量、使用量、剩余量， 以及档案系统的格式与相关信息等；
• inode：记录档案的属性，一个档案占用一个inode，同时记录此档案的资料所在的block 号码；
• block：实际记录档案的内容，若档案太大时，会占用多个block 。

Superblock 是文件系统最基本的元数据，它定义了文件系统的类似、大小、状态，和其他元数据结构的信息（元数据的元数据）。

Superblock 对于文件系统来说是非常关键的，因此对于每个文件系统它都冗余存储了多份。Superblock对于文件系统来说是一个非常“高等级”的元数据结构。例如，如果 /var 分区的 Superblock 损坏了，那么 /var 分区将无法挂载。在这时候，一般会执行 fsck 来自动选择一份

只破坏superblock： 
新建文件系统 挂载 复制文件dd if=/dev/zero of=/dev/sdb1 bs=4k count=1
df -Th查看异常 
fsck（filesystem check）
fsck -v -y /dev/sdb1 
重载后 文件就恢复正常了
（用的后面备份的超级块修复的，必须要卸载修复。挂载修复容易损坏文件系统）

Superblock 备份来替换损坏的 Superblock，并尝试修复文件系统。主 Superblock 存储在分区的 block 0 或者 block 1 中，而 Superblock 的备份则分散存储在文件系统的多组 block 中。当需要手工恢复时，我们可以使用 dumpe2fs /dev/sdb1 | grep -i superblock 来查看 sdb1 分区的 superblock 备份有哪一份是可用的。我们假设 dumpe2fs 输出了这样一行：Backup superblock at 163840, Group descriptors at 163841-163841 ，通过这条信息，我们就可以尝试使用这个 superblock 备份：/sbin/fsck.ext3 -b 163840 -B 1024 /dev/sda1。请注意，这里我们假设 block 的大小为 1024 字节。

破坏superblock与大量inode_table等元数据信息以及data_block（会有数据丢失）：
复制文件dd if=/dev/zero of=/dev/sdb1 bs=4M count=100破坏大量文件
需要指定backup_super_block位置来恢复超级块文件
可以通过fdisk创建相同大小与文件格式的新空间来查找backup_super_block位置
fdisk add sdb2   
dumpe2fs /dev/sdb2 ｜ grep -i super
查找到了backup_super_block位置，
在ext文件系统下，也可以通过 mke2fs -n /dev/sdb2来模拟创建过程，找出backup_super_block位置
通过e2fsck -b superblock_number device来修复，找到正确的数字会提示修复

Inode 中包含了一个文件的元数据。为清晰起见，Linux/Unix 系统中的所有对象均为文件：实际的文件、目录、设备等等。请注意，在 Inode 所包含的元数据中，并没有文件名。一个 Inode 包含的基本信息有：所有权（用户，组），访问模式（读、写、执行权限）和文件类型。

Dentry 是将 Inode 和 文件联系在一起的”粘合剂”，它将 Inode number 和文件名联系起来。Dentry 也在目录缓存中扮演了一定的角色，它缓存最常使用的文件以便于更快速的访问。Dentry 还保存了目录及其子对象的关系，用于文件系统的遍历。

Linux 的EXT2 档案系统(inode)

inode的内容在记录档案的权限与相关属性，至于block区块则是在记录档案的实际内容。而且档案系统一开始就将inode与block规划好了，除非重新格式化(或者利用resize2fs等指令变更档案系统大小)，否则inode与block固定后就不再变动。但是如果仔细考虑一下，如果我的档案系统高达数百GB时，那么将所有的inode与block通通放置在一起将是很不智的决定，因为inode与block的数量太庞大，不容易管理。

为此，因此Ext2 档案系统在格式化的时候基本上是区分为多个区块群组(block group) 的，每个区块群组都有独立的 inode/block/superblock 系统。感觉上就好像我们在当兵时，一个营里面有分成数个连，每个连有自己的联络系统， 但最终都向营部回报连上最正确的信息一般！这样分成一群群的比较好管理啦！整个来说，Ext2 格式化后有点像底下这样：

在整体的规划当中，档案系统最前面有一个开机磁区(boot sector)，这个开机磁区可以安装开机管理程式，这是个非常重要的设计，因为如此一来我们就能够将不同的开机管理程式安装到个别的档案系统最前端，而不用覆盖整颗磁盘唯一的MBR，这样也才能够制作出多重开机的环境啊！至于每一个区块群组(block group)的六个主要内容说明如后：

data block (资料区块)

data block是用来放置档案内容资料地方，在Ext2档案系统中所支持的block大小有1K, 2K及4K三种而已。在格式化时block的大小就固定了，且每个block都有编号，以方便inode的记录啦。不过要注意的是，由于block大小的差异，会导致该档案系统能够支持的最大磁盘容量与最大单一档案容量并不相同。因为block大小而产生的Ext2档案系统限制如下：

除此之外Ext2 档案系统的block 还有什么限制呢？有的！基本限制如下：

• 原则上，block 的大小与数量在格式化完就不能够再改变了(除非重新格式化)；
• 每个block 内最多只能够放置一个档案的资料；
• 承上，如果档案大于block 的大小，则一个档案会占用多个block 数量；
• 承上，若档案小于block ，则该block 的剩余容量就不能够再被使用了(磁盘空间会浪费)。

inode table (inode 表格)

基本上，inode记录的档案资料至少有底下这些：

• 该档案的存取模式(read/write/excute)；
• 该档案的拥有者与群组(owner/group)；
• 该档案的容量；
• 该档案建立或状态改变的时间(ctime)；
• 最近一次的读取时间(atime)；
• 最近修改的时间(mtime)；
• 定义档案特性的旗标(flag)，如SetUID…；
• 该档案真正内容的指向(pointer)；

inode 的数量与大小也是在格式化时就已经固定了，除此之外inode 还有些什么特色呢？

• 每个inode 大小均固定为128 bytes (新的ext4 与xfs 可设定到256 bytes)；
• 每个档案都仅会占用一个inode 而已；
• 承上，因此档案系统能够建立的档案数量与inode 的数量有关；
• 系统读取档案时需要先找到inode，并分析inode 所记录的权限与使用者是否符合，若符合才能够开始实际读取 block 的内容。

我们粗略来分析一下EXT2 的inode / block 与档案大小的关系好了。inode 要记录的资料非常多，但偏偏又只有128bytes 而已， 而inode 记录一个block 号码要花掉4byte ，假设我一个档案有400MB 且每个block 为4K 时， 那么至少也要十万笔block 号码的记录呢！inode 哪有这么多可记录的信息？为此我们的系统很聪明的将inode 记录block 号码的区域定义为12个直接，一个间接, 一个双间接与一个三间接记录区。这是啥？我们将inode 的结构画一下好了。

这样子inode 能够指定多少个block 呢？我们以较小的1K block 来说明好了，可以指定的情况如下：

• 12个直接指向： 12*1K=12K
  由于是直接指向，所以总共可记录12笔记录，因此总额大小为如上所示；
• 间接： 256*1K=256K
  每笔block号码的记录会花去4bytes，因此1K的大小能够记录256笔记录，因此一个间接可以记录的档案大小如上；
• 双间接： 256*256*1K=256 2 K
  第一层block会指定256个第二层，每个第二层可以指定256个号码，因此总额大小如上；
• 三间接： 256*256*256*1K=256 3 K
  第一层block会指定256个第二层，每个第二层可以指定256个第三层，每个第三层可以指定256个号码，因此总额大小如上；
• 总额：将直接、间接、双间接、三间接加总，得到12 + 256 + 256*256 + 256*256*256 (K) = 16GB

Superblock (超级区块)

记录的信息主要有：

• block 与inode 的总量；
• 未使用与已使用的inode / block 数量；
• block 与inode 的大小(block 为1, 2, 4K，inode 为128bytes 或256bytes)；
• filesystem 的挂载时间、最近一次写入资料的时间、最近一次检验磁盘(fsck) 的时间等档案系统的相关信息；
• 一个valid bit 数值，若此档案系统已被挂载，则valid bit 为0 ，若未被挂载，则valid bit 为1 。

一般来说， superblock的大小为1024bytes。相关的superblock讯息我们等一下会以dumpe2fs指令来呼叫出来观察喔！

此外，每个block group 都可能含有superblock喔！但是我们也说一个档案系统应该仅有一个superblock 而已，那是怎么回事啊？事实上除了第一个block group 内会含有superblock 之外，后续的block group 不一定含有superblock ， 而若含有superblock 则该superblock 主要是做为第一个block group 内superblock 的备份咯，这样可以进行superblock的救援呢！

Filesystem Description (档案系统描述说明)

这个区段可以描述每个block group的开始与结束的block号码，以及说明每个区段(superblock, bitmap, inodemap, data block)分别介于哪一个block号码之间。这部份也能够用dumpe2fs来观察的。

block bitmap (区块对照表)

如果你想要新增档案时总会用到block 吧！那你要使用哪个block 来记录呢？当然是选择『空的block 』来记录新档案的资料啰。那你怎么知道哪个block 是空的？这就得要透过block bitmap 的辅助了。从block bitmap 当中可以知道哪些block 是空的，因此我们的系统就能够很快速的找到可使用的空间来处置档案啰。

同样的，如果你删除某些档案时，那么那些档案原本占用的block 号码就得要释放出来， 此时在block bitmap 当中相对应到该block 号码的标志就得要修改成为『未使用中』啰！这就是bitmap 的功能。

inode bitmap (inode 对照表)

这个其实与block bitmap 是类似的功能，只是block bitmap 记录的是使用与未使用的block 号码， 至于inode bitmap 则是记录使用与未使用的inode 号码啰！

dumpe2fs： 查询Ext 家族superblock 信息的指令

[root@study ~]# dumpe2fs [-bh]装置档名
选项与参数：
-b ：列出保留为坏轨的部分(一般用不到吧！？)
-h ：仅列出superblock 的资料，不会列出其他的区段内容！

范例：一块1GB ext4档案系统内容 
[root@study ~]# blkid    <==这个指令可以叫出目前系统有被格式化的装置
/dev/vda1: LABEL="myboot" UUID="ce4dbf1b-2b3d-4973-8234-73768e8fd659" TYPE="xfs"
/dev/vda2: LABEL="myroot" UUID="21ad8b9a-aaad-443c-b732-4e2522e95e23" TYPE="xfs"
/dev/vda3: UUID="12y99K-bv2A-y7RY-jhEW-rIWf-PcH5-SaiApN" TYPE="LVM2_member"
/dev/vda5: UUID="e20d65d9-20d4-472f-9f91-cdcfb30219d6" TYPE="ext4"   <==看到ext4了！

[root@study ~]# dumpe2fs /dev/vda5
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name: <none>            #档案系统的名称(不一定会有) 
Last mounted on: <not available>   #上一次挂载的目录位置
Filesystem UUID: e20d65d9-20d4-472f-9f91-cdcfb30219d6 
Filesystem magic number: 0xEF53            #上方的UUID为Linux对装置的定义码 
Filesystem revision #: 1 (dynamic)       #下方的features为档案系统的特征资料
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit
 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             #这块档案系统的状态为何，clean是没问题
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536             # inode的总数 
Block count: 262144            # block的总数 
Reserved block count: 13107             #保留的block总数 
Free blocks: 249189            #还有多少的block可用数量 
Free inodes: 65525             #还有多少的inode可用数量
First block: 0
Block size: 4096              #单个block的容量大小
Fragment size: 4096
Group descriptor size: 64
....(中间省略).... 
Inode size: 256               # inode的容量大小！已经是256了喔！
....(中间省略)....
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 3c2568b4-1a7e-44cf-95a2-c8867fb19fbc
Journal backup: inode blocks
Journal features: (none)
Journal size: 32M               # Journal日志式资料的可供纪录总容量
Journal length: 8192
Journal sequence: 0x00000001
Journal start: 0

Group 0: (Blocks 0-32767)                   #第一块block group位置
  Checksum 0x13be, unused inodes 8181
  Primary superblock at 0, Group descriptors at 1-1    #主要superblock的所在喔！
  Reserved GDT blocks at 2-128
  Block bitmap at 129 (+129), Inode bitmap at 145 (+145)
  Inode table at 161-672 (+161)                        # inode table的所在喔！
  28521 free blocks, 8181 free inodes, 2 directories, 8181 unused inodes
  Free blocks: 142-144, 153-160, 4258-32767            #底下两行说明剩余的容量有多少
  Free inodes: 12-8192
Group 1: (Blocks 32768-65535) [INODE_UNINIT]           #后续为更多其他的block group喔！

# 前半部在秀出supberblock 的内容，包括标头名称(Label)以及inode/block的相关信息
# 后面则是每个block group 的个别信息了！您可以看到各区段资料所在的号码！
# 也就是说，基本上所有的资料还是与block 的号码有关就是了！很重要！

今天的文章superblock损坏_black-box分享到此就结束了，感谢您的阅读。