只有1个字节的文件实际占用多少磁盘空间

图片

在前文《新建一个空文件占用多少磁盘空间?》中我们了解到了一个空文件的磁盘开销。 今天我们再思考另外一个问题,假如我们给文件里只写入1个字节,那么这个文件实际的磁盘占用多大,难道真的是1个字节吗?

1查看1个字节的文件

和前文一样,先不谈原理,直接动手操作。

# mkdir tempDir
# cd tempDir
# du -h
0    .
# touch test
# du -h
0    .

在一个目录中创建了一个空的文件以后,通过du命令看到的该文件夹的占用空间并没有发生变化。这符合我们之前的认识,因为空文件只占用inode。好,那让我们修改文件,添加一个字母

echo "a" > test
# du -h
4.0K    .

保存后再次查看该目录的空间占用。我们发现由原来的0增加到了4K。 所以说,文件里的内容不论多小,哪怕是一个字节,其实操作系统也会给你分配4K的。哦,当然了还得再算前文中说到的inode和文件夹数据结构中存储的文件名等所用的空间。 所以,不要在你的系统里维护一大堆的碎文件。文件再小,占用磁盘其实一点都不少!

注意我的实验环境是在ext文件系统下进行的。如果是xfs可能表现会有些许出入。

2继续讨论这个4K

再把linux源代码文件fs/ext2/ext2.h里关于inode的定义翻出来,我们找到结构体中定义的指向数据节点用的block数组:

struct ext2_inode {
   ......
   __le32  i_block[EXT2_N_BLOCKS]; # 指向存储文件数据的块的数组
   ......

当文件没有数据需要存储的时候,这个数组都是空值。而当我们写入了1个字节以后,文件系统就需要申请block去存储了,申请完后,指针放在这个数组里。哪怕文件内容只有一个字节,仍然会分配一个整的Block,因为这是文件系统的最小工作单位。那么这个block大小是多大呢,ext下可以通过dumpe2fs查看。

#dumpe2fs -h /dev/mapper/vgroot-lvroot
......
Block size:               4096

在我的机器上,一个Block是4KB。

3文件内容大了怎么办?

不知道你留意没,inode中定义的block数组大小呢,只有EXT2_N_BLOCKS个。我们再查看一下这个常量的定义,发现它是15,相关内核中定义如下:

#define EXT2_NDIR_BLOCKS        12
#define EXT2_IND_BLOCK         EXT2_NDIR_BLOCKS
#define EXT2_DIND_BLOCK        (EXT2_IND_BLOCK + 1)
#define EXT2_TIND_BLOCK        (EXT2_DIND_BLOCK + 1)
#define EXT2_N_BLOCKS              (EXT2_TIND_BLOCK + 1)

就按4K的block size来看,15个block只够存的下15*4=60K的文件。 这个文件大小相信你一定不满意,你存一个avi大片都得上G了。那Linux是怎么实现大文件存储的呢?嗯,其实上面宏的定义过程已经告诉你了,就是只有12个数组直接存block指针,其余的用来做间接索引(EXT2_IND_BLOCK),二级间接索引(EXT2_DIND_BLOCK)和三级索引(EXT2_TIND_BLOCK)。

图片图1 inode中的直接与间接索引

这样,一个文件可以使用的空间就指数倍的扩展了。 文件小的时候,都用直接索引,磁盘IO少,性能好。文件大的时候,访问一个block可能得先进行三次的IO,性能略慢,不过有OS层面的页缓存、目录项缓存的加持,也还好。

4结论

文件系统是按照inode+block来组织的,所以不管你的文件多小,哪怕只有一个字节,在数据上都会消耗掉整整一个块(当然还得算上inode等开销)。这个块大小可以通过dumpe2fs等命令来查看。如果想改变这个块大小怎么办?对不起,只能重新格式化。

再扯的远一点,所有的文件系统理念都是按照块来分配的,包括分布式文件系统,例如HDFS。由于HDFS应用场景是各种GB、TB甚至是PB级别的数据处理。所以为了降低block的管理成本,它的block size设置的非常大。在比较新的版本里,一个block直接就是128M,你没看错,单位是M。 所以如果你没有block的概念,天天在HDFS上都保存一堆KB级别的小文件,就等着去财务处领钱吧!



猜你喜欢

转载自blog.51cto.com/15057824/2627771