我想知道我的 Ubuntu 服务器的总磁盘空间。我发现了这个问题：使用命令行获取 Linux 中硬盘的总大小，无需 root 权限。 这已接受且得票最多的答案建议以下命令：
dmesg | grep blocks
我运行它并得到以下结果：
EXT4-fs (xvda1): resizing filesystem from 2096891 to 39321339 blocks
我是 Ubuntu 新手，我试图理解上面一行的含义。我怀疑我能否从这些数字中轻松判断出我的硬盘总大小。这条消息对我来说很神秘。那么为什么链接的答案被点赞了？我还应该知道什么来“解码”这条消息？
或者我的情况有些特殊？其他人是否能从中获得不那么神秘的结果dmesg | grep blocks？我感觉有些事情不正常。我另外担心的是，这是在调整服务器中的磁盘空间大小还是其他什么？我应该担心吗？
请帮助我理解dmesg | grep blocks在链接答案的上下文中应该做什么。我得到的行是预期的结果吗？我如何从中获取磁盘的总大小？
我大概知道该做什么，dmesg并grep自行做事。
答案1
链接的答案称该命令为“一种黑客方式”，并说“这可能不是理想的”。这是有原因的。不幸的是，答案没有说明会发生什么，也没有说明命令工作需要什么。难怪你感到困惑。
该命令并未向您显示链接答案的作者的想法。您看到的行与作者的想法无关。
你写了你大概知道什么dmesg和grep做什么。对于一般观众，让我们明确一点：
dmesg打印内核环形缓冲区；将缓冲区视为一个日志，它会告诉您 Linux 操作系统内部发生了什么。grep过滤其输入并打印与模式匹配的行；如果grep blocks模式为blocks。dmesg | grep blocks获取内核环缓冲区并对其进行过滤，因此只有包含字符串的行blocks才能通过；事实上，您得到的行包含该字符串。
当我在 Kubuntu 18.04.5 LST 中运行时dmesg | grep blocks，输出如下：
[ 6.028374] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
[ 6.635725] sd 1:0:0:0: [sdb] 1465149168 512-byte logical blocks: (750 GB/699 GiB)
这不是全部的输出，我省略了几行不相关的内容。我没有省略的是我认为链接答案的作者所考虑的部分。从这些行中，人们可以很容易地知道我的磁盘的大小。
dmesg | grep blocks可能不会打印出这些内容，原因可能是：
- 可能需要
sudo运行dmesg。这就是它在我的 Debian 10 中的工作方式。对于你的情况，这个原因显然不适用：如果你需要sudo，你会得到一个明显的错误（operation not permitted或类似的东西），而不是你得到的那行。 - 打印的
dmesg是缓冲区，其大小是有限的。如果缓冲区已满，则新条目将使缓冲区丢弃旧条目。在长期运行的操作系统中，与链接答案相关的条目可能已被丢弃（它们可能仍在/var/log/kern.log或类似的日志中）。虽然这可能发生在你的情况下，但我怀疑它是否真的发生了。通常你可以通过分析来判断是否开始丢弃dmesg | head。如果时间戳那么您就0.000000知道缓冲区仍然存储着内核启动时的事件，所以后续的条目也应该仍然存在。 - 缓冲区不包含链接答案作者想要的条目。这可能是您遇到的情况。
我展示的示例条目来自负责管理sda或等设备的 sd 驱动程序sdb。最初这些名称表示 SCSI 磁盘。现在它不仅限于 SCSI。请参阅这个答案，尤其是其中说的：
如今，Linux 调用大多数可重写的大容量存储设备
/dev/sd?。
sd?您很可能在相关操作系统中没有任何设备，这就是为什么您没有看到来自 sd 驱动程序的行。您观察到的行提到了xvda1，这个和类似名称的设备是特定于 Xen。
请注意，sd 驱动程序会生成如下消息
sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
只是因为有人在某个时候认为它很有用。通常，块设备驱动程序不需要以这种方式报告每个设备的大小。无论处理您的什么xvda1都不会生成此类消息。
现在应该清楚链接的答案有点滥用dmesg。答案被赞成是因为绝大多数非虚拟 Linux 操作系统实际上使用由 sd 驱动程序处理的磁盘。答案被接受只是因为问题的作者最喜欢它。在目前的状态下，答案提供了一个可能有用的解决方案，但没有任何见解；在我看来，这不是一个高质量的答案。
现在你得到以下行：
EXT4-fs (xvda1): resizing filesystem from 2096891 to 39321339 blocks
出现是因为它当时在缓冲区中并且包含blocks（模式grep blocks搜索的内容）；但它与链接答案的作者所想的无关。从某种意义上说，dmesg | grep blocks它是偶然打印出来的。
这行代码可能来自resize2fs，这是一款用于调整 ext 系列文件系统大小的工具。您应该了解以下内容：
- 该行表示文件系统
xvda1已调整大小。请记住，dmesg打印的所有内容都是日志，日志中的所有内容都已发生。调整大小发生在操作系统上次启动之后（即上次重启之前），但肯定不是因为您调用了dmesg。 - 我无法告诉你为什么会发生调整大小。即使这是由于某种自动化而发生的（我并不声称这是自动化的），我当然不希望每次重启时都会发生这种情况。
resize2fs可以在线扩大文件系统（即挂载时）。如果一切正常，则无需担心。请记住，调整大小已经发生。- 该行实际上不能告诉您总磁盘空间，因为：
- 它告诉您文件系统现在占用 39321339 个块，但没有告诉您一个块有多大；
- 但即使您知道一个块有多大，39321339 个块是文件系统的新大小，设备本身可能会更大；
- 并且设备是
xvda1，所以它可能是某个更大的分区xvda，甚至可能大得多； - 并且可能还有其他块设备。
使用dmesg | grep blocks来查找块设备的大小就像在农夫的日记中搜索“重量”一词以了解他每头猪的重量一样。日记中可能提到了重量，也可能没有；也许提到了农夫的重量（或他妻子的重量）。正确的方法是将每头猪放在秤上。对于您来说，该命令没有提供任何有用的信息。寻找另一个命令，真正为这项工作而设计的命令，就像秤是用来测量重量的一样。我的第一选择是lsblk或lsblk -b。请注意，lsblk打印块设备的大小（类似于在正确情况下所讨论的命令将打印的内容），而不是文件系统的大小或文件系统中的可用空间。