11

Can I find free space of unmounted partition using system files like sys or proc?

I know how to find total space but have no idea about free space. Please suggest using system files only. For total space of unmounted partition I am using /proc/partitions file.

Vlastimil Burián
  • 28,462
Sarthak_Bhutani
  • 413

5 Answers5

7

There is no general way for that, but there is a way which works in most cases.

The reason why there is no general way for that is that the kernel doesn't know it either. To know it, it would first need to analyze the partition.

Without mounting the partition, the kernel knows only about its existence, but no more. Essentially, it is a line of blocks with random data. The kernel knows where it is and how to access it, but doesn't know what to do with it.

However, there are also user-space tools which can analyze the content of a filesystem without mounting it. As all filesystems have very different data structures, you need different tools to handle them.

In the case of ext2/3/4, it is

# dumpe2fs /dev/sdxN|grep '^Free blocks'
dumpe2fs 1.42.13 (17-May-2015)
Free blocks:              5721580

Or the (by far faster) tune2fs tool:

# tune2fs -l /dev/sdxN|grep '^Free blocks:'
Free blocks:              14227371
aaaaaa123456789
  • 103
peterh
  • 9,731
  • I liked your solution, but was unable to correlate the value of "Free blocs" with the effective free space in bytes. On my /home , command "df -B 1 /home" gave me 50736435200 free 1B blocks. command tune2fs gave me 21665008 (note: i set 0% reserved for root). How one can correlate both value ? Naively dividing one by the other doesn't gave any clue .... – binarym Dec 24 '21 at 15:36
  • @binarym Merry Christmas! About 2015 years ago, the Universe got a new direction on a level which is essentially inaccessible by our science and technology. About your problem: df -B 1 gives back the free space in bytes (1-byte blocks). Tune2fs gives it back the free space in the size of the blocks used by the filesystem (nearly always 4096 bytes, but sometimes it can be 1024 or 2048 as well). That is the cause of the difference. But multiplying the tune2fs with 4096, we get about 8GB. I think you have seen the total disk size in tune2fs. – peterh Dec 24 '21 at 17:06
  • Merry Christmas @peterh ! I can admit that i was tired last day i tried ... but feel free to tell me how to get the best result, here are the output of tune2fs -l , df -h and df -B 1 for my home partition: https://pastebin.com/24SwqEhd As you said, multiplying 21665008 (Free blocks) by 4096 (block size) is supposed to give me the free space in bytes ... just like df -B 1 is supposed to, right ? 'Cause here, it doesn't compute :-( – binarym Dec 27 '21 at 09:02
  • @binarym My pleasure! You are right, that is really not okay. I think the most likely cause is: sparse files. Sparse file means a file whose some blocks are not allocated. Some databases are using this feature. Here is a site, how can you find them. In essence: use the command find / -type f -printf "%S\t%p\n" | gawk '$1 < 1.0 {print}' in /home. – peterh Dec 27 '21 at 14:54
  • @binarym If this does not work, then unmount the filesystem, do an fsck and mount it back. It is because another possible cause of the trouble that something has an open filedescriptor to some deleted big files. On Unix, you can still delete opened files, but they will be really deleted only if that process closes them. But you can unmount the partition only if all files are closed on it. So an umount, fsck, mount is a for-sure fix for similar problems (except if there are sparse files). – peterh Dec 27 '21 at 14:56
  • I think you're right ... i was soo obsessed by this problem that i wrote a MWE using regular file + loop and guess what ? The values were ok (even if there's a small (acceptable) delta between df / lsblk and the tune2fs method. I think my /home partition has something broken ;-) – binarym Dec 27 '21 at 17:56
  • @binarym 1) find the sparse files 2) if there is none, then unmount, fsck, mount and it should be okay. I do not understand this loop thing, your log shows an LVM volume (irrelevant, ext4 see a block device and that is all). – peterh Dec 27 '21 at 22:22
6

procfs should be used specifically for process related info. (as it is not stictly followed but still to be on safer side don't depend on it as there is chance of it getting deprecated).

so sysfs will give us system info. this will give info of full disk size [in sectors, not in bytes].

cat /sys/block/sda/size

replace sda with your partition name.

ls /sys/block/sda/

will give info about partitions available check for directory naming sda1, sda2 ...

same thing as sda can be used to check size [sectors] of these partitions.

cat /sys/block/sda/sda1/size

Also you can check your output using

sudo fdisk -l /dev/sda1

This is real example: enter image description here Same note as above watch partition names. change sda to sdb,sdc, etc according to your requirement.

If you wants to get drive or partiton size in bytes use blockdev.

Андрей Тернити
  • 213
Devidas
  • 507
  • 1
    without mounting the partition I doubt we will be able to read free blocks. there is draw back doing so because this info will be written multiple time to update which may be harmful for disk life. so after disk is mounted and scanned this info is available to you. – Devidas Oct 03 '17 at 06:29
  • 1
    It shows the number of all blocks on the partition, not the free ones. – peterh Oct 04 '17 at 02:27
  • Yeah you are right peterh. So I have added comment above stating "without mounting the partition I doubt we will be able to read free blocks". I meant in sysfs or procfs. there are other utilities as stated, but he asked for procfs or sysfs so I mentioned it. what I meant while answering was there is a place where info about all partition is stored in kernel but free scpace is not one of them. – Devidas Oct 04 '17 at 06:56
  • If the partition is trimmable (i.e. SSD drive), then it would be possible to count the freed blocks among the partition boundaries. Probably no tool exists for that, but it would be possible. I would not close out that this information is available somewhere below /sys. – peterh Oct 21 '19 at 19:34
4

This is dependent on the filesystem type, but you could try to use fsck to find out how much free space there is left. Finding the free space requires a tool that understands the structure of the filesystem, and there usually aren't many of those in addition to fsck.

Johan Myréen
  • 13,168
2

I don't know if it can be done, as you say, "using system files only," but you can use resize2fs to get an estimate without mounting. From the man page:

       -M     Shrink the file system to minimize its size as much as possible,
              given the files stored in the file system.

       -P     Print an estimate of the number of file  system  blocks  in  the
              file system if it is shrunk using resize2fs's -M option and then
              exit.

So, resize2fs -P /dev/PARTITION will give you an estimate of how many blocks the filesystem on that partition is taking up. Total blocks on the partition can be found, as you said, from /proc/partitions, or with blockdev --getsz /dev/PARTITION, then do a little bit of arithmetic. I don't know how close the estimated minimum size is to the actual disk usage, but I'm guessing the minimum size is larger than the actual disk usage, to give some leeway. We can check by mounting it and running du.

Stephen C
  • 825
2
# cfdisk /dev/sda

This command will show unmounted and unpartitioned space contained in /dev/sda as per screenshot below:

enter image description here

Bruce Malaudzi
  • 1,589