0.2秒居然复制了100G文件? 我给同事讲了一个小时,他感动得快哭了...

简介: 0.2秒居然复制了100G文件? 我给同事讲了一个小时,他感动得快哭了...


cp 引发的思考



今天同事用 cp 命令,把他给惊到了!

背景是这样的:他用 cp  拷贝了一个 100 G的文件,竟然一秒不到就拷贝完成了!

ls  看一把文件,显示文件确实是 100 G。

sh-4.4# ls -lh
-rw-r--r-- 1 root root 100G Mar  6 12:22 test.txt

但是copy起来为什么会这么快呢?

sh-4.4# time cp ./test.txt ./test.txt.cp
real 0m0.107s
user 0m0.008s
sys 0m0.085s

一个 SATA 机械盘的写能力能到 150 M/s (大部分的机械盘都是到不了这个值的)就算非常不错了,正常情况下,copy 一个 100G 的文件至少要 682 秒 ( 100 G/ 150 M/s ),也就是 11 分钟。

实际情况却是 cp 一秒没到就完成了工作,惊呆了,为啥呢?

更诡异的是:他的文件系统只有 40 G,为啥里面会有一个 100 G的文件呢?

同事把我找来,看看这个诡异的问题。


分析文件


我让他先用 du 命令看一下,却只有 2M ,根本不是100G,这是怎么回事?

sh-4.4# du -sh ./test.txt
2.0M ./test.txt

再看 stat 命令显示的信息:

sh-4.4# stat ./test.txt
  File: ./test.txt
  Size: 107374182400 Blocks: 4096       IO Block: 4096   regular file
Device: 78h/120d Inode: 3148347     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-13 12:22:00.888871000 +0000
Modify: 2021-03-13 12:22:46.562243000 +0000
Change: 2021-03-13 12:22:46.562243000 +0000
 Birth: -

stat 命令输出解释:

  1. Size 为 107374182400(知识点:单位是字节),也就是 100G ;
  2. Blocks 这个指标显示为 4096(知识点:一个 Block 的单位固定是 512 字节,也就是一个扇区的大小),这里表示为 2M;

划重点

  • Size 表示的是文件大小,这个也是大多数人看到的大小;
  • Blocks 表示的是物理实际占用空间

同事问道:文件大小和实际物理占用,这两个竟然不是相同的概念 !为什么是这样?  

“看来,我们必须得深入文件系统才能理解了,来,我给你好好讲讲。”



文件系统



文件系统听起来很高大上,通俗话就用来存数据的一个容器而已,本质和你的行李箱、仓库没有啥区别,只不过文件系统存储的是数字产品而已。

我有一个视频文件,我把这个视频放到这个文件系统里,下次来拿,要能拿到我完整的视频文件数据,这就是文件系统,对外提供的就是存取服务


现实的存取场景


例如你到火车站使用寄存服务:

存行李的时候,是不是要登记一些个人信息?对吧,至少自己名字要写上。可能还会给你一个牌子,让你挂手上,这个东西就是为了标示每一个唯一的行李。22.gif取行李的时候,要报自己名字,有牌子的给他牌子,然后工作人员才能去特定的位置找到你的行李33.gif划重点:存的时候必须记录一些关键信息(记录ID、给身份牌),取的时候才能正确定位到。


文件系统


回到我们的文件系统,对比上面的行李存取行为,可以做个简单的类比;

  1. 登记名字就是在文件系统记录文件名;
  2. 生成的牌子就是元数据索引;
  3. 你的行李就是文件;
  4. 寄存室就是磁盘(容纳东西的物理空间);
  5. 管理员整套运行机制就是文件系统;

上面的对应并不是非常严谨,仅仅是帮助大家理解文件系统而已,让大家知道其实文件系统是非常朴实的一个东西,思想都来源于生活。


空间管理


现在思考文件系统是怎么管理空间的?

如果,一个连续的大磁盘空间给你使用,你会怎么使用这段空间呢?

直观的一个想法,我把进来的数据就完整的放进去。

image.gif这种方式非常容易实现,属于眼前最简单,以后最麻烦的方式。因为会造成很多空洞,明明还有很多空间位置,但是由于整个太大,形状不合适(数据大小),哪里都放不下。因为你要放一个完整的空间。

怎么改进?有人会想,既然整个放不进去,那就剁碎了呗。这里塞一点,那里塞一点,就塞进去了。

对,思路完全正确。改进的方式就是切分,把空间按照一定粒度切分。每个小粒度的物理块命名为 Block,每个 Block 一般是 4K 大小,用户数据存到文件系统里来自然也是要切分,存储到磁盘上各个角落。

image.gif图示标号表示这个完整对象的 Block 的序号,用来复原对象用的。

随之而来又有一个问题:你光会切成块还不行,取文件数据的时候,还得把它们给组合起来才行。

所以,要有一个表记录文件对应所有 Block 的位置,这个表被文件系统称为inode

写文件的流程是这样的:

  1. 先写数据:数据先按照 Block 粒度存储到磁盘的各个位置;
  2. 再写元数据:然后把 Block 所在的各个位置保存起来,即inode(我用一本书来表示);

33.gif读文件流程则是:

  1. 先读inode,找到各个 Block 的位置;
  2. 然后读数据,构造一个完整的文件,给到用户;

image.png

inode/block 概念


好,我们现在来看看inode,直观地感受一下:image.png这个inode有文件元数据Block数组(长度是15),数组中前两项指向Block 3和Block 11,表示数据在这两个块中存着。

你肯定会意识到:Block数组只有15个元素,每个Block是4K, 难道一个文件最大只能是 15 * 4K =  60 K ?  

这是绝对不行的!

最简单的办法就是:把这个Block数组长度给扩大!

比如我们想让文件系统最大支持100G的文件,Block数组需要这么长:

(100*1024*1024)/4 = 26214400

Block数组中每一项是4个字节,那就需要(26214400*4)/1024/1024 = 100M

为了支持100G的文件,我们的Block数组本身就得100M !

并且对每个文件都是如此 !即使这个文件只有1K! 这将是巨大浪费!

肯定不能这么干,解决方案就是间接索引,按照约定,把这 15 个槽位分作 4 个不同类别来用:

  1. 前 12 个槽位(也就是 0 - 11 )我们成为直接索引
  2. 第 13 个位置,我们称为 1 级索引
  3. 第 14 个位置,我们称为 2 级索引
  4. 第 15 个位置,我们称为 3 级索引

image.png直接索引:能存 12 个 block 编号,每个 block 4K,就是 48K,也就是说,48K 以内的文件,前 12 个槽位存储编号就能完全 hold 住。

一级索引

也就是说这里存储的编号指向的 block 里面存储的也是 block 编号,里面的编号指向用户数据。一个 block  4K,每个元素 4 字节,也就是有 1024 个编号位置可以存储。

所以,一级索引能寻址 4M(1024 * 4K)空间 。image.png二级索引

二级索引是在一级索引的基础上多了一级而已,换算下来,有了 4M 的空间用来存储用户数据的编号。所以二级索引能寻址 4G (4M/4 * 4K) 的空间。

image.png三级索引

三级索引是在二级索引的基础上又多了一级,也就是说,有了 4G 的空间来存储用户数据的 block 编号。所以二级索引能寻址 4T (4G/4 * 4K) 的空间。

image.png所以,在这种文件系统(如ext2)上,通过这种间接块索引的方式,最大能支撑的文件大小 = 48K + 4M + 4G + 4T ,约等于 4 T。

这种多级索引寻址性能表现怎么样?

在不超过 12 个数据块的小文件的寻址是最快的,访问文件中的任意数据理论只需要两次读盘,一次读 inode,一次读数据块。

访问大文件中的数据则需要最多五次读盘操作:inode、一级间接寻址块、二级间接寻址块、三级间接寻址块、数据块。


为什么cp那么快?


接下来我们要写入一个奇怪的文件,这个文件很大,但是真正的数据只有8K:

在[0,4K]这位置有4K的数据

在[1T , 1T+4K] 处也有4K数据

中间没有数据,这样的文件该如何写入硬盘?

  1. 创建一个文件,这个时候分配一个 inode;
  2. 在 [ 0,4K ] 的位置写入 4K 数据,这个时候只需要 一个 block,把这个编号写到 block[0] 这个位置保存起来;
  3. 在 [ 1T,1T+4K ] 的位置写入 4K 数据,这个时候需要分配一个 block,因为这个位置已经落到三级索引才能表现的空间了,所以需要还需要分配出 3 个索引块;
  4. 写入完成,close 文件;

实际存储如图image.png这个时候,我们的文件看起来是超大文件,size 等于 1T+4K ,但里面实际的数据只有 8 K,位置分别是  [ 0,4K ] ,[ 1T,1T+4K ]。

由于没写数据的地方不用分配物理block块,所以实际占用的物理空间只有8K。

重点:文件 size 只是 inode 里面的一个属性,实际物理空间占用则是要看用户数据放了多少个 block ,没写数据的地方不用分配物理block块。

这样的文件其实就是稀疏文件, 它的逻辑大小和实际物理空间是不相等的。

所以当我们用cp命令去复制一个这样的文件时,那肯定迅速就完成了。


总结


好,我们再深入思考下,文件系统为什么能做到这一点?

  1. 首先,最关键的是把磁盘空间切成离散的、定长的 block 来管理;
  2. 然后,通过 inode 能查找到所有离散的数据(保存了所有的索引);
  3. 最后,实现索引块和数据块空间的后分配;

这三点是层层递进的。


相关文章
|
3月前
|
算法 安全
关于我用半个月过了软件设计师这件事
这篇文章分享了作者在半个月内通过软件设计师考试的经验,包括快速刷视频了解知识体系、针对性地刷历年真题并根据错题加强知识点巩固、进行模拟考试和总结,以及使用笔记软件记录重要知识点的方法。
关于我用半个月过了软件设计师这件事
|
程序员 开发工具 开发者
以为是使用电脑的老手,没想到吃了没备份数据的亏。
以为是使用电脑的老手,没想到吃了没备份数据的亏。
|
存储 算法 Linux
实习生的代码被弄丢了!救命的时候绝对用的上——每天三分钟玩转Git (8)
实习生的代码被弄丢了!救命的时候绝对用的上——每天三分钟玩转Git (8)
实习生的代码被弄丢了!救命的时候绝对用的上——每天三分钟玩转Git (8)
|
小程序 数据安全/隐私保护 计算机视觉
切勿外传,我要把我的写作“小心思”放出来了!| 年终总结之学习篇🚩
切勿外传,我要把我的写作“小心思”放出来了!| 年终总结之学习篇🚩
177 0
切勿外传,我要把我的写作“小心思”放出来了!| 年终总结之学习篇🚩
|
SQL 缓存 Java
在项目中随手把haseMap改成了currenHaseMap差点被公司给开除了。
在项目中随手把haseMap改成了currenHaseMap差点被公司给开除了。
142 0
|
敏捷开发 人工智能 安全
周末来个王炸!!
为了让学习更有趣,这篇文章我会列出计算机科学理论和一些概念,并且用类比的方式和尽量少的技术术语来为你进行解释。这样做的目的就是为了让你快速了解计算机,查漏补缺。
周末来个王炸!!
|
开发框架 安全 .NET
你真的了解计算机病毒吗?内容很“干”,记得喝水(上)
计算机病毒与计算机相伴生的东西,它对计算机的安全构成一定的威胁,一旦病毒计算机遭到病毒入侵,轻则导致信息丢失,重则导致电脑瘫痪。因此,抵御病毒入侵显得十分重要。 想要抵御病毒,你得先了解它们,知道它们长什么样子,是如何侵入计算机的才能很好的抵御它们。
你真的了解计算机病毒吗?内容很“干”,记得喝水(上)
|
存储 人工智能 监控
你真的了解计算机病毒吗?内容很“干”,记得喝水(下)
计算机病毒与计算机相伴生的东西,它对计算机的安全构成一定的威胁,一旦病毒计算机遭到病毒入侵,轻则导致信息丢失,重则导致电脑瘫痪。因此,抵御病毒入侵显得十分重要。 想要抵御病毒,你得先了解它们,知道它们长什么样子,是如何侵入计算机的才能很好的抵御它们。
你真的了解计算机病毒吗?内容很“干”,记得喝水(下)
有一次小明传数据给我,把我弄哭了
某天小明处理的一些数据需要传给我这边处理,于是小明在我们的传输媒介上面新增了一个 Map 用于保存这些数据,数据结构如下:
122 0
|
Web App开发 程序员
亲爱的老板:程序员的10分钟就是3个小时
导读:国外程序员艾德·韦斯曼(Ed Weissman )从业32年。某天老板告诉他产品有个问题,10分钟可以修复问题,谁知结果一干就是3个小时。本文就是艾德记录下的过程。 10:48 老板:嗨,艾德,苏在底特律说,“产品历史屏幕”上经常出现错误的发票号码(Invoice Part Number)。
921 0