云盘不是硬盘,所售即所得-阿里云开发者社区

开发者社区> 阿里云支持与服务> 正文

云盘不是硬盘,所售即所得

简介: 一般来说,我们可以把排查问题的技术分成三层。底下是理论知识,上边是问题模式【注释1】,夹在理论知识和问题模式之间的是工具。而贯穿排查技术的是“用数据说话”。今天这篇文章,跟大家分享一例我与客户"用数据说话"的故事。

一般来说,我们可以把排查问题的技术分成三层。底下是理论知识,上边是问题模式【注释1】,夹在理论知识和问题模式之间的是工具。而贯穿排查技术的是“用数据说话”。今天这篇文章,跟大家分享一例我与客户"用数据说话"的故事。

“您有问题截图吗?”,“没有,但我能背出来。”

客户直接通过钉钉联系我:“有一个奇葩问题要你看了”。通过简单的沟通,我了解到,客户的业务程序使用一个200G的云盘做数据盘,晚上11点30的时候,业务程序由于不能写入数据而报错。这里关键的问题在于,客户声称当时磁盘并没有用光。

因为踩过不少坑,所以就算是熟客,我还是很专(jing)业(ti)地问了一句,“您有当时问题现场的截图吗?”。客户的回答让我哭笑不得:“没有,但是我能背出来”。接着呢,客户可能觉得口说无凭,就画了下边这张图给我。这里我想说的是,我们平时在跟客户处理问题的时候,总会听到客户各种各样的描述,但是最关键的沟通,还是数据沟通,比如一个报错,或者一个性能截图。然而,客户画一个性能数据给我做,这真的是第一次。

从这张手写的使用情况的截图来看,文件系统vdb1共有197G的可用空间,其中被用掉的空间是186G。这里让人难以理解的地方在于,空间使用率居然已经是100%了。

云盘不是硬盘

要想给客户解释这些“不合理”的数字,我们需要从磁盘的最基本单位说起。不管是云盘,还是传统的硬盘,都是以块为最小单位,进行数据存取的。这一点类似于我们平时读书:数只能一页一页的读,我们只要读到某一页,就能看到一整页的文字。我们没有办法只打开某一行,或者某一个字去读书。一般而言,磁盘块的大小是固定的512个字节。那么,客户购买的200G的云盘,到底是多少个字节呢?

之所以有这个提问,是因为传统的硬件厂商在售卖硬盘的时候,使用的换算单位是1000。也就是说,200G的硬盘应该是200,000,000,000个字节。那么我们卖给客户的200G的云盘,也是这么大吗?其实阿里云在售卖云盘的时候,使用的换算单位是并不是传统的1000,而是1024。有一个简单的办法可以验证这件事情。我们可以读/sys/block/vdb/size文件,得到vdb这个云盘的总块数。以200G云盘为例,我们读到的块数是419430400,每块512字节,那么200G的云盘,实际上是214748364800个字节。【注释2】

分区管理成本

了解了磁盘的最基本单位之后,我们眼中的磁盘,差不多就变成下边这个样子了:一块磁盘由若干个512字节的块组成。

然而,习惯上我们不会直接的,从第一块到最后一块这样去使用磁盘。我们要先对磁盘进行分区。客户的200G数据盘只有一个分区,所以分区之后大概是下边这样的。前边的黑色块是分区管理成本。这部分应该首先从可用空间中减掉。客户的数据盘中,分区管理成本是1M。

 文件系统管理成本

分区之后,我们需要在分区之上,创建文件系统。文件系统是我们可以直接使用的存取数据的方式。在分区之上创建文件系统,有点类似于我们拿到一个空白的笔记本,对笔记本的使用做一些简单的规划,其中一部分用来写日记,一部分做计算等,然后根据不同的用途,编写一个目录。这里的“目录”,是文件系统的管理成本。这部分内容,也是需要从可用空间中减掉的。对于Linux文件系统来说,这部分开销最主要是inode结构。如下图,vdb1这个文件系统一共有13107200个inode,每个inode256个字节。那么这部分成本是不能忽略的一部分成本:3.125G。【注释3】

问题重现了一半

减掉分区成本和文件系统成本,200G的云盘,可用的空间就剩下197G了。这与Size的值相匹配。但这显然不能解释,为什么只用掉186G,空间使用率就到100%了。在百思不得其解之后,我决定自己动手试试,看能不能跑出客户看到的问题。我申请了一个云服务器,挂载了一个200G的云盘,然后连续创建1G大小的空白文件。在跑了大概30分钟以后,我看到下边的结果。结果证明,客户当时应该是真的看到了他手写的那个数据。

但是,当我尝试继续往磁盘里写空白文件的时候,我并没有看到客户所说的,磁盘空间不足的报错,直到197G被全部用完为止。

工具df不生产数据

所有的秘密都藏在工具df里。工具df可以用来查看磁盘的容量以及剩余空间,但是就像Linux上很多其他工具一样,df并不会凭空的产生数据。df命令使用系统调用从内核拿到数据,然后加工并把相对可读的信息提供给用户。研究df的行为,我们可以使用strace。用strace追踪df的执行过程,我们发现与磁盘容量相关的数据均来自于系统调用statfs。

下边这条记录,是在重现环境中抓的。我们可以看到,statfs以文件系统挂载路劲为输入,输出一个包含此文件系统统计信息的结构体。

statfs("/mnt", {f_type=EXT2_SUPER_MAGIC, f_bsize=4096, f_blocks=51572986, f_bfree=2557603, f_bavail=0, f_files=13107200, f_ffree=13107176, f_fsid={3186720966, 3846989262}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0

在这个结构体中,f_bsize记录的是文件系统的块大小,这个和磁盘块大小是类似的概念。可以看到文件系统的块大小是4K,也就是说,1个文件系统块,需要使用8个磁盘块。f_blocks是文件系统总块数,df输出的文件系统的Size就是从这个值计算而来。

而跟这个“奇葩”问题相关的,是f_bfree和f_bavail这两个值。这两个值从命名来看都可以解释为可用空间,但意义却大不一样。根据定义,f_bfree是文件系统的可用块数,这个值是df输出的Size和Used的差值。而f_bavail,是“非特权”用户的可用块。Linux在创建文件系统的时候,会预留一部分磁盘空间,专门给root使用,默认情况下,这部分空间是磁盘空间的5%。f_bavail记录的是,从非特权用户视角看,磁盘的可用空间。

明白了上边几个数据项的含义之后,这个问题就变得很清楚了。之所以Used才到186G的时候,空间使用率就已经到了100%,是因为df计算使用率,用的是f_bavail,而不是f_bfree。换句话说,df使用的是非特权用户的视角。因为客户业务进程使用的并不是root账户,所以业务进程在使用到186G的时候报出磁盘空间不足的错误就不足为奇了。

大图

最后我们来看一下大图。200G的云盘,分区和文件系统,会用掉3G的管理成本。剩下197G就是df输出的Size值,也就是真正的可用磁盘空间。因为文件系统会预留5%的空间给特权用户使用,这大概是10G,所以对非特权用户来说,可用空间需要再减掉10G,所以大概就剩187G。

后记

在排查问题的过程中,我们必然会用到各种各样的数据和指标,毫不夸张地说,我们分析问题,解决问题的过程,就是收集数据,研究数据,以及使用数据和客户沟通的过程。而基础排查和进阶排查的一个最很重要的区别,就是我们能不能从数据本身出发,一层一层深入到数据产生的源头当中去,深入到加工数据的代码当中去,理解数据产生的原因。以今天这个问题为例,当我们弄清楚磁盘容量这些指标的计算方法之后,这个问题就变得非常的简单,但是,如果我们不能这样一步一步的深入去探究,那么这个问题就是显得奇葩而不可解释。

 

  • 注释1:问题模式这个概念和设计模式类似。设计模式是最佳实践,是软件开发领域,典型问题和经典解法的总结。而问题模式,也是类似的概念。当我们处理过大量问题之后,会自然而然的遇到一些典型的重复的场景,当然也会使用一些重复的处理方法。

  • 注释2:云盘和硬盘换算单位的差别,严格来说,是GiB和GB的差别。云盘使用的是GiB,而硬盘使用的是GB。但是使用中我们比较少对这两者做区分。

  • 注释3:文件系统还有其他一些管理开销,比如superblock等,因为占比很小,这里忽略掉了。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

分享阿里云支持与服务团队最佳实践、经典案例与故障排查。

官方博客
文档