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.

  • bro it gives total space of the partition. Oct 6 '17 at 4:55

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
  • 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: 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 9: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

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.

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 of these partitions.

cat /sys/block/sda/sda1/size

Same note as above watch partition names. change sda to sdb,sdc, etc according to your requirement.

Hope this answers your question.

  • 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 3 '17 at 6:29
  • 1
    It shows the number of all blocks on the partition, not the free ones.
    – peterh
    Oct 4 '17 at 2: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 4 '17 at 6: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

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.

# cfdisk /dev/sda 

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

enter image description here


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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.