“dmesg | grep blocks” - Does this command really show the total disk space?

Solution 1:

The linked answer calls the command "a hacky way" and says "this might not be ideal". There are reasons for this. Unfortunately the answer does not say what to expect nor what is required for the command to work. No wonder you got confused.

The command did not show you what the author of the linked answer thought of. The line you saw has nothing to do with what the author had in mind.

You wrote you roughly know what dmesg and grep do. For the general audience let's make it clear:

• dmesg prints the kernel ring buffer; think of the buffer as of a log that tells you what happened in the guts of your Linux OS.
• grep filters its input and prints lines matching a pattern; in case of grep blocks the pattern is blocks.
• dmesg | grep blocks gets the kernel ring buffer and filters it, so only lines containing the string blocks pass through; indeed the line you got contains the string.

When I run dmesg | grep blocks in my Kubuntu 18.04.5 LST, the output is like:

[    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)

It's not the entire output, I omitted few irrelevant lines. What I did not omit is the part I think the author of the linked answer had in mind. From these lines one can easily tell the sizes of my disks.

dmesg | grep blocks may print nothing like these and the reason(s) may be:

• One may need sudo to run dmesg. This is how it works in my Debian 10. In your case this reason apparently does not apply: if you needed sudo, you would get a clear error (operation not permitted or so), not the line you got.
• What dmesg prints is a buffer and its size is limited. If the buffer is full then new entries will make the buffer drop old entries. In a long-running OS the entries relevant in the context of the linked answer may have already been dropped (they may still be in /var/log/kern.log or similar log). While this may have happened in your case, I doubt it did actually happen. Usually you can tell if dropping began by analyzing dmesg | head. If the timestamps are 0.000000 then you know the buffer still stores events from when the kernel booted, so later entries should also still be there.
• The buffer does not and did not contain entries the author of the linked answer had in mind. This is what probably happened in your case.

The example entries I've shown come from the sd driver responsible for managing devices like sda or sdb. Originally these names meant SCSI disks. Nowadays it's not limited to SCSI. See this answer, especially from where it says:

Today, Linux calls most rewritable mass-storage devices /dev/sd?.

You most likely don't have any sd? device in the OS in question, that's why you observed no lines from the sd driver. The line you observed mentions xvda1, this and similarly named devices are specific to Xen.

Note the fact the sd driver generates a message like

sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)

is only because someone at some point though it was useful. In general block device drivers are not required to report the size of each device this way. Whatever handles your xvda1 does not generate such message.

Now it should be clear the linked answer kinda abuses dmesg. The answer is upvoted because the vast majority of non-virtual Linux OSs actually uses disks handled by the sd driver. The answer is accepted only because the author of the question there liked it the most. In its current state the answer gives a potentially useful solution without any insight; IMO it's not a high quality answer.

Now the line you got:

EXT4-fs (xvda1): resizing filesystem from 2096891 to 39321339 blocks

appeared because it was in the buffer at the time and it contains blocks (the pattern grep blocks searches for); but it has nothing to do with what the author of the linked answer had in mind. In some sense dmesg | grep blocks printed it by chance.

The line is probably from resize2fs, a tool designed to resize filesystems from the ext family. This is what you should know:

• The line indicates the filesystem on xvda1 has been resized. Keep in mind everything dmesg prints is a log, everything in the log has already happened. The resizing happened after the OS last started (i.e. not before the last reboot) but certainly not because you invoked dmesg.
• I cannot tell you why the resizing happened. Even if it happened because of some automation (and I don't claim it did), I certainly don't expect it to happen every time you reboot.
• resize2fs can enlarge a filesystem online (i.e. when it's mounted). If everything works then there's nothing to be worried about. Remember the resizing has already happened.
• The line cannot really tell you the total disk space because:
  • it tells you the filesystem now takes 39321339 blocks but it doesn't tell you how big one block is;
  • but even if you knew how big one block is, 39321339 blocks is the new size of the filesystem, the device itself may be larger;
  • and the device is xvda1, so probably it's a partition of some xvda which is even larger, maybe substantially larger;
  • and there may be other block devices.

Using dmesg | grep blocks to find out the sizes of block devices is like searching for the word "weight" in a farmer's diary to learn the weight of each of his pigs. Maybe the diary mentions the weights, maybe not; maybe it mentions the farmer's weight (or his wife's). A proper method is to put each pig on a scale. In your case the command tells nothing useful. Find another command, something actually designed for the job, like the scale is designed to measure weight. My first choice would be lsblk or lsblk -b. Note lsblk prints sizes of block devices (similarly to what the command in question would print in the right circumstances), not sizes of filesystems nor free space in filesystems.