戏说文件系统之ext2【上】

    前面说过，虚拟文件系统VFS是对各种文件系统的一个抽象层，抽取其共性，以便对外提供统一管理接口，便于内核对不同种类的文件系统进行管理。那么首先我们得看一下对于一个具体的文件系统，我们该关注重点在哪里。

     对于存储设备(以硬盘为例)上的数据，可分为两部分：

     用户数据：存储用户实际数据的部分；

     管理数据：用于管理这些数据的部分，这部分我们通常叫它元数据(metadata)。

     我们今天要讨论的就是这些元数据。这里有个概念首先需要明确一下：块设备。所谓块设备就是以块为基本读写单位的设备，支持缓冲和随机访问。每个文件系统提供的mk2fs.xx工具都支持在构建文件系统时由用户指定块大小，当然用户不指定时会有一个缺省值。在博文“硬盘的存储原理和内部架构”里我们提到过，硬盘的每个扇区512字节，而多个相邻的若干扇区就构成了一个簇，从文件系统的角度看这个簇对应的就是我们这里所说块。用户从上层下发的数据首先被缓存在块设备的缓存里，当写满一个块时数据才会被发给硬盘驱动程序将数据最终写到存储介质上。如果想将设备缓存中数据立即写到存储介质上可以通过sync命令来完成。上一篇博文里我们也说，块越大存储性能越好，但浪费比较严重；块越小空间利用率较高，但性能相对较低。如果你不是专业的“骨灰级”玩儿家，在存储设备上构建文件系统时，块大小就用默认值。通过命令“tune2fs -l /dev/sda1”可以查看该存储设备上文件系统所使用的块大小：

[root@localhost ~]# tune2fs -l /dev/sda1
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   /boot
Last mounted on:
Filesystem UUID:          6ade5e49-ddab-4bf1-9a45-a0a742995775
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              38152
Block count:              152584
Reserved block count:     7629
Free blocks:              130852
Free inodes:              38111
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         2008
Inode blocks per group:   251
Filesystem created:       Thu Dec 13 00:42:52 2012
Last mount time:          Tue Nov 20 10:35:28 2012
Last write time:          Tue Nov 20 10:35:28 2012
Mount count:              12
Maximum mount count:      -1
Last checked:             Thu Dec 13 00:42:52 2012
Check interval:           0 ()
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      72070587-1b60-42de-bd8b-a7b7eb7cbe63
Journal backup:           inode blocks

    该命令已经暴露了文件系统的很多信息，接下我们将详细分析它们。

     下图是我的虚拟机的情况，三块IDE的硬盘。容量分别是：

      hda: 37580963840/(1024*1024*1024)=35GB

      hdb: 8589934592/(1024*1024*1024)=8GB

      hdd: 8589934592/(1024*1024*1024)=8GB

     如果这是三块实际的物理硬盘的话，厂家所标称的容量就分别是37.5GB、8.5GB和8.5GB。可能有些童鞋觉得虚拟机有点“假”，那么我就来看看实际硬盘到底是个啥样子。

     主角1：西部数据 500G SATA接口 CentOS 5.5

     实际容量：500107862016B = 465.7GB

     主角2：希捷 160G  SCSI接口 CentOS 5.5

     实际容量：160041885696B=149GB

    大家可以看到，VMware公司的水平还是相当不错的，虚拟硬盘和物理硬盘“根本”看不出差别，毕竟属于云平台基础架构支撑者的风云人物嘛。

   以硬盘/dev/hdd1为例，它是我新增的一块新盘，格式化成ext2后，根目录下只有一个lost+found目录，让我们来看一下它的布局情况，以此来开始我们的文件系统之旅。

     对于使用了ext2文件系统的分区来说，superblock的大小为1024字节，其实ext3的superblock也是1024字节。下面的小程序可以证明这一点：

#include <stdio.h>
#include <linux/ext2_fs.h>
#include <linux/ext3_fs.h>

int main(int argc,char** argv){
    printf("sizeof of ext2 superblock=%d\n",sizeof(struct ext2_super_block));
    printf("sizeof of ext3 superblock=%d\n",sizeof(struct ext3_super_block));
        return 0;
}

     输出结果如下：

     硬盘的第一个字节是从0开始编号，所以第一个字节是byte0，以此类推。/dev/hdd1分区头部的1024个字节(从byte0~byte1023)都用0填充，因为/dev/hdd1不是主引导盘。superblock是从byte1024开始，占1024B存储空间。我们用dd命令把superblock的信息提取出来：

dd if=/dev/hdd1 of=./hdd1sb bs=1024 skip=1 count=1

     上述命令将从/dev/hdd1分区的byte1024处开始，提取1024个字节的数据存储到当前目录下的hdd1sb文件里，该文件里就存储了我们superblock的所有信息，如下：

     上面的程序稍加改造，我们就可以以更直观的方式看到superblock的输出了：

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <linux/ext2_fs.h>
#include <linux/ext3_fs.h>

int main(int argc,char** argv){
    printf("sizeof of ext2 superblock=%d\n",sizeof(struct ext2_super_block));
    printf("sizeof of ext3 superblock=%d\n",sizeof(struct ext3_super_block));
    char buf[1024] = {0};
    int fd = -1;
    struct ext2_super_block hdd1sb;
    memset(&hdd1sb,0,1024);

    if(-1 == (fd=open("./hdd1sb",O_RDONLY,0777))){
        printf("open file error!\n");
        return 1;
    }

    if(-1 == read(fd,buf,1024)){
        printf("read error!\n");
        close(fd);
        return 1;
    }

    memcpy((char*)&hdd1sb,buf,1024);
    printf("inode count : %ld\n",hdd1sb.s_inodes_count);
    printf("block count : %ld\n",hdd1sb.s_blocks_count);
    printf("Reserved blocks count : %ld\n",hdd1sb.s_r_blocks_count);
    printf("Free blocks count : %ld\n",hdd1sb.s_free_blocks_count);
    printf("Free inodes count : %ld\n",hdd1sb.s_free_inodes_count);
    printf("First Data Block : %ld\n",hdd1sb.s_first_data_block);
    printf("Block size : %ld\n",1<<(hdd1sb.s_log_block_size+10));
    printf("Fragment size : %ld\n",1<<(hdd1sb.s_log_frag_size+10));
    printf("Blocks per group : %ld\n",hdd1sb.s_blocks_per_group);
    printf("Fragments per group : %ld\n",hdd1sb.s_frags_per_group);
    printf("Inodes per group : %ld\n",hdd1sb.s_inodes_per_group);
    printf("Magic signature : 0x%x\n",hdd1sb.s_magic);
    printf("size of inode structure : %d\n",hdd1sb.s_inode_size);
    close(fd);
    return 0;
}

     打印结果如下：

     对于ext2/ext3文件系统来说数字签名Magic signature都是0xef53，如果不是那么它一定不是ext2/ext3文件系统。这里我们可以看到，我们的/dev/hdd1确实是ext2文件系统类型。hdd1中一共包含1048576个inode节点(inode编号从1开始)，每个inode节点大小为128字节，所有inode消耗的存储空间是1048576×128=128MB；总共包含2097065个block，每个block大小为4096字节，每32768个block组成一个group，所以一共有2097065/32768=63.99，即64个group(group编号从0开始，即Group0～Group63)。 所以整个/dev/hdd1被划分成了64个group，详情如下：

     用命令tune2fs可以验证我们之前的分析：

     再通过命令dumpe2fs /dev/hdd1的输出，可以得到我们关注如下部分：

     接下来以Group0为例，主superblock在Group0的block0里，根据前面的分析，我们可以画出主superblock在block0中的位置如下：

     因为superblock是如此之重要，一旦它出错你的整个系统就玩儿完了，所以文件系统中会存在磁盘的多个不同位置会存在主superblock的备份副本，一旦系统出问题后还可以通过备份的superblock对文件系统进行修复。第一版ext2文件系统的实现里，每个Group里都存在一份superblock的副本，然而这样做的负面效果也是相当明显，那就是严重降低了磁盘的空间利用率。所以在后续ext2的实现代码中，选择用于备份superblock的Group组号的原则是3^N、5^N、7^N其中N=0,1,2,3…。根据这个公式我们来计算一下/dev/hdd1中备份有supeblock的Group号：

     也就是说Group1、3、5、7、9、25、27、49里都保存有superblock的拷贝，如下：

     用block号分别除以32768就得到了备份superblock的Group号，和我们在上面看到的结果一致。我们来看一下/dev/hdd1中Group和block的关系：

     从上图中我们可以清晰地看出在使用了ext2文件系统的分区上，包含有主superblock的Group、备份superblock的Group以及没有备份superblock的Group的布局情况。存储了superblock的Group中有一个组描述符(Group descriptors)紧跟在superblock所在的block后面，占一个block大小；同时还有个Reserved GDT跟在组描述符的后面。

     Reserved GDT的存在主要是支持ext2文件系统的resize功能，它有自己的inode和data block，这样一来如果文件系统动态增大，Reserved GDT就正好可以腾出一部分空间让Group descriptor向下扩展。

     未完，待续...