How to view unallocated free space on a hard disk through terminal [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
I want to view the unallocated free space on my hard disk through terminal. I’ve burned my brains searching the internet for a possible solution, but all in vain. I used all sorts of commands like df , du , fdisk , parted , etc. It tells me about the disks that are mounted and unmounted, but what about the unallocated space that I’ve left free? Of course I can view it using the ‘Disk Utility’ app provided by Fedora, but since I LOVE being in the terminal I’d like to view in it. Can anyone please help me with a solution?
You might have a misunderstanding about free space. Don’t forget overhead, and do remember that open(2) -ed but unlink(2) -ed files still use disk space.
This may be considered off-topic for Stack Overflow. You might want to ask about this on Unix.SE or Super User (but search for it there first!).
13 Answers 13
Use GNU parted and print free command:
root@sandbox:~# parted GNU Parted 2.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print free Model: VMware Virtual disk (scsi) Disk /dev/sda: 64.4GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 32.3kB 1049kB 1016kB Free Space 1 1049kB 256MB 255MB primary ext2 boot 256MB 257MB 1048kB Free Space 2 257MB 64.4GB 64.2GB extended 5 257MB 64.4GB 64.2GB logical lvm 64.4GB 64.4GB 1049kB Free Space The command to use/reclaim that free space depends on where that free space is located, between existing partitions, and what kind of partitions you have (primary, extended) and also if you use LVM or not. It’s not trivial to just run a simple command that will read your mind and know what you want to actually do with that free space 🙂
# parted /dev/sda unit TB print free | grep ‘Free Space’ | tail -n1 | awk »
# parted /dev/sda unit GB print free | grep ‘Free Space’ | tail -n1 | awk »
# parted /dev/sda unit MB print free | grep ‘Free Space’ | tail -n1 | awk »
# parted /dev/sda unit B print free | grep ‘Free Space’ | tail -n1 | awk »
# parted /dev/sda unit ‘%’ print free | grep ‘Free Space’ | tail -n1 | awk »
# parted /dev/sda unit s print free | grep ‘Free Space’ | tail -n1 | awk »
Change /dev/sda to whatever device you are trying to find the information about. If you are using the result in any calculations, make sure to trim the trailing characters.
By adding the —machine argument to the parted invocation, you get colon separated output which will be much more reliable to parse than the default human readable output.
With the parted commands like this, parted will run in interactive mode. If this isn’t intended, the «unit TB» and «print free» commands need to swap places. This is also how the —help option shows it: first the command, then command args. The full command would then be: parted /dev/sda print free unit TB
The simplest way to show unallocated free space in a single command:
$ sudo sfdisk --list-free /dev/sdX (Add the —quiet option if you don’t need the extra info about sector size, etc.)
In addition to all the answers about how to find unpartitioned space, you may also have space allocated to an LVM volume but not actually in use. You can list physical volumes with the pvdisplay and see which volume groups each physical volume is associated with. If a physical volume isn’t associated with any volume group, it’s safe to reallocate or destroy. Assuming that it it is associated with a volume group, the next step is to use vgdisplay to show your those. Among other things, this will show if you have any free «physical extents» — blocks of storage you can assign to a logical volume. You can get this in a concise form with vgs :
$ sudo vgs VG #PV #LV #SN Attr VSize VFree fedora 1 3 0 wz--n- 237.46g 0 . and here you can see I have nothing free. If I did, that last number would be bigger than zero.
This is important, because that free space is invisible to du , df , and the like, and also will show up as an allocated partition if you are using fdisk or another partitioning tool.
vgdisplay really was the answer for me, as with most installers today a great option is to go with encrypted LVM which creates volume groups with logical volumes within. Then when moving space around the unallocated space is in the volume group, not the physical volume partitions.
I had just the same trouble with fedora 26 and LVM partitions, it seems I forgot check something during the installation, So, my 15G root directory has been increased to 227G like I needed.
I posted the steps I followed here:
0) #df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 824K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/fedora-root 15G 2.1G 13G 14% / tmpfs 1.9G 0 1.9G 0% /tmp /dev/md126p1 976M 119M 790M 14% /boot tmpfs 388M 0 388M 0% /run/user/0 1) # vgs VG #PV #LV #SN Attr VSize VFree fedora 1 2 0 wz--n- 231.88g 212.96g 2) # vgdisplay --- Volume group --- VG Name fedora System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 231.88 GiB PE Size 4.00 MiB Total PE 59361 Alloc PE / Size 4844 / 18.92 GiB Free PE / Size 54517 / 212.96 GiB VG UUID 9htamV-DveQ-Jiht-Yfth-OZp7-XUDC-tWh5Lv 3) # lvextend -l +100%FREE /dev/mapper/fedora-root Size of logical volume fedora/root changed from 15.00 GiB (3840 extents) to 227.96 GiB (58357 extents). Logical volume fedora/root successfully resized. 4) #lvdisplay 5) #fd -h 6) # xfs_growfs /dev/mapper/fedora-root meta-data=/dev/mapper/fedora-root isize=512 agcount=4, agsize=983040 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1 spinodes=0 rmapbt=0 = reflink=0 data = bsize=4096 blocks=3932160, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 3932160 to 59757568 7) #df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 1.9G 0 1.9G 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 1.9G 828K 1.9G 1% /run tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup /dev/mapper/fedora-root 228G 2.3G 226G 2% / tmpfs 1.9G 0 1.9G 0% /tmp /dev/md126p1 976M 119M 790M 14% /boot tmpfs 388M 0 388M 0% /run/user/0 How to check empty space in a folder using commandline?
Folders are as big as the total size of their contents; they do not have any free space.
The df command shows empty disk space.
Strange. You got a down-vote. not sure why (answer is perfectly fine) but you did. Our site needs more upvotes, here’s one to remove that nasty -1 😉
There is no meaning of a folder size. In really a folder/directory is just a File in Linux as the concept everything is a file in Linux.
So a folder is a file of files. I,e it’s just a place to hold files, though it has no size, its size is related to the size of files inside.
So, there is nothing called free space on a folder.
You can know the size of a directory
also you can know the free space of your whole filesystem
Just to clarify it a little more (hope i do not miss any special filesystem):
- Folders are a small file
- Folders grow as more files / sub folders are added to it (but not to a sub folder of it), only directly to it
- Folders (on some systems do not) decrease on size when files / sub folders directly on it are removed from it
- Think on folders as a phonebook list
- Most filesystems leave empty entries on folders (just to not move all the rest up), so size most of the times only grows
- Folder size does not include any file size (unless such folder is a container where talking about free space may have a meaning: size to reach max container size)
- Folder size depends on the number of entries (including the ones than have been blanked) ceiling it to a multiply of a number
- Folders does not hold inside it any content of any file (except special folders that are really a container, with or without a max size defined)
At least for FAT12, FAT16, FAT32, exFAT, NTFS, ext, ext2, ext3, ext4, and maybe for much more filesystems, folders are a small file that identifies what folders and files are under it, just like a phonebook list, it only describes what is inside it (beware: only directly on it, nothing about what is inside any sub folder).
NTTS has some extra things, but all has it’s unique identificator (a number), folders identify only what of such identificators are just directly on such folder, not the ones that are in a sub folder of it, etc.
Beware there are filesystems very special, on that ones a Folder can have a size (upper limit) and so it has sence to talk about free space inside that folder.
For most Linux users to understand that, treat such Folder as a Container with a max size, concept is near the VDI files of VirtualBOX, etc. They can grow up to a limited size. Some special filesystems use that concept for a Folder, while others (like Pismo Private Folders) use a no max size limit.
For most Windows users to understand that, treat such Folder a a sparse big file, that with some 3rd part tool is seen as a folder.
In other words, the are three common well defined type of thing on a file system (including some special filesystems not so much common to see):
- Files (hold information, or links to other files)
- Normal folders, they are really a small file (hold a list of what is directly on its 1st level inside them)
- Special folders, they can be seen as a huge file, with or without an upper size limit (holds all what is inside them, list and content of all, including sub folders, etc); not all filesystems allow them natively, most use the trick of defining a file and then mount it as if it where a folder (like .zip, .rar, .7z mounter utilities, etc), but a few filesystems allow them natively.
If you want to see something very weird, try this (on a NTFS):
- Create a folder on the root, called for example: MyWeirdFolder
- Then inside it create a sub folder with a very large name (more than 200 characters)
- Create another folder, but with a short name, like WillBeRenamed
- Move the long one inside the short one
- Rename the short one to a very long name (more than 200) characters
You will get a path that is not accesible due to very long path, just rename such long names to shorter ones and will get access to it again.