Drive partitioning
While I do a lot of things from the command line, managing partitions and formatting drives is normally not one of those.
Maybe I find fdisk and similar programs too confusing, or maybe of got burned in the past so badly that I subconsciously decided that I should use graphical programs for this particular task. I believe the main motivation why I tend to prefer graphical applications that guide you for this particular task, is that I do not format drives or create partitions that often.
Working from the command line is great, especially if you can automate part of your workflow, and with some experience, you are generally more efficient than using a graphical application. For a task that I do once or twice a year, efficiency or a task that takes top a couple of minutes is not really a concern, and there is little experience to accumulate; next time I’ll have to format a drive I’ll have to learn it again.
So why those notes?
I had to format a drive on a device without a GUI. Since it was an internal drive, I could not simply format it on another machine.
I could have installed a graphical program like GParted on the machine, but it would have added a lot of dependencies for just one program. I could have removed the program after using it, but it is a not well-maintained machine, and installing those programs would have updated some dependencies too, which might have some side effects.
Sure, there are ways to overcome those limitations, but it gets complicated, and probably at this point it is just easier to format the drive from the command line.
Formatting drives is one of the easiest ways to lose data, from the command line (at least that is my feeling) it is not always obvious what is going to happen. I suppose that I do not know enough about partitions, and/or most tools command-line tools are too "low level".
It does not help that every tutorial suggest slightly different commands, and the differences are not obvious.
Graphical tools like the KDE Partition Manager and GParted give a good overview about what drives and partitions will be modified, and how they will be modified.
Even when using those tools, I always remove all external drives that I do not want to modify; there is no reason to take unnecessary risks.
Then I noticed that KDE Partition Manager shows which commands it executes! So the idea I had was to use KDE Partition Manager on my machine on a thumb drive, see what tools it uses underneats, read the manual in order to understand whats happening, and use the same tools one the machine without a GUI!
KDE Partition Manager
My first test was to format a USB stick to ext4. The detailed output of KDE Partition Manager is more verbose, I just copied out the commands and added some comments:
# delete partition(s)
wipefs --all /dev/sdc1
sfdisk --force --delete /dev/sdc 1
# create a new partition on /dev/sdc
sfdisk --force --append /dev/sdc
# create file system ext4 on /dev/sdc1
mkfs.ext4 -qF /dev/sdc1
sfdisk --part-type /dev/sdc 1 83
# set the file system label
e2label /dev/sdc1 LABEL
# check file system
e2fsck -f -y -v /dev/sdc1
umount /dev/sdc1The second test was to format a USB stick to fat32:
# delete file system
wipefs --all /dev/sdc1
# delete partition
sfdisk --force --delete /dev/sdc 1
# create a new partition on /dev/sdc
sfdisk --force --append /dev/sdc
# create file system ext4 on /dev/sdc1
mkfs.fat -F32 -I -v /dev/sdc1
sfdisk --part-type /dev/sdc 1 c
# set the file system label
fatlabel /dev/sdc1 label
# check file system
fsck.fat -a -w -v /dev/sdc1
umount /dev/sdc1It looks good, but does it really work? No. Lucky me, I decided to test the commands out on my machine and realized that sfdisk --force --append /dev/sdc is interactive! Hopefully, in the future 🗄️ the output will be something that one can execute directly.
The man pages of sfdisk says:
sfdisk is a script-oriented tool for partitioning any block device. It runs in interactive mode if executed on a terminal (stdin refers to a terminal).
So I executed : | sfdisk --force --append /dev/sdc; it does not start sfdisk interactively, but it won’t change anything on the drive, and subsequent commands will fail.
In this case, the correct command seems to be echo ',' | sfdisk --force --append /dev/sdc; it adds a new partition that spans the whole remaining space on the drive.
GParted
I knew that GParted also provided a similar detailed overview to the executed operations, so I tried it out.
The name stands for "GUI parted", and since the KDE Partition Manager does not use parted, I wanted to see what parted commands were used for formatting a drive.
Only at this point, I realized that GParted shows a different type of detailed information.
In particular, it does not show the parted commands:
create empty partition 00:00:01 ( SUCCESS )
path: /dev/sdc1 (partition)
start: 2048
end: 4028415
size: 4026368 (1.92 GiB)
clear old file system signatures in /dev/sdc1 00:00:02 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 0 00:00:00 ( SUCCESS )
write 4.00 KiB of zeros at byte offset 67108864 00:00:00 ( SUCCESS )
write 512.00 B of zeros at byte offset 2059919872 00:00:00 ( SUCCESS )
write 512.00 KiB of zeros at byte offset 2060976128 00:00:00 ( SUCCESS )
flush operating system cache of /dev/sdc 00:00:01 ( SUCCESS )
set partition type on /dev/sdc1 00:00:01 ( SUCCESS )
new partition type: fat32Thus, there is no information on how to reproduce from the command line what GParted did, except the command used for creating the actual file system:
mkfs.fat -F32 -v -I -n "LABEL" /dev/sdc1I suppose that the details I excepted are not shown because GParted does not execute the command-line tools parted, but uses the library libparted, which is shared by both tools.
cfdisk
After documenting the commands used by the KDE Partition Manager, and reading the documentation, I found out there is also cfdisk.
cfdisk is a curses-based program for managing partitions, after using it a little bit, it is something I will definitively consider in the future. It might not provide all the advanced options, but I find it much easier to use it than fdisk or sfdisk. It is interactive, but that’s not an issue (efficiency is not a main concern), but contrary to graphical tools it does not handle file systems. Thus you still have to create a file system by yourself after partitioning the drive; for example:
-
mkfs.ext4 -qF /dev/sdc1 -
e2label /dev/sdc1 LABEL -
e2fsck -f -y -v /dev/sdc1
The rabbit hole
After reading here and there, I encountered many topics, too many to document them all. Especially because there are so many open questions, contradictory statements, and so little time (and I do not have the hardware to make all the tests I would like).
I found a lot of interesting data on the archlinux wiki. I’m sure there are other websites that provide a lot of information about this topic too, but this is where I landed and search engines redirected me there most of the time, if one excludes SEO-optimized websites with little content and too many tracking scripts.
nvme-format
I found out there is nvme-format 🗄️.
-
Should I prefer it when formatting an NVME drive?
-
Do graphical tools use it when available?
-
What advantages does it offer compared to
fdiskorparted?
MBR and GPT partitions
MBR stands for Master Boot Record, and GPT stands for GUID Partition Table.
All contemporary computers with UEFI support GPT, older devices with "only" a BIOS might or might not support GPT.
As documented by Microsoft 🗄️ all 64 bit version of Windows from Windows Vista Service Pack 1 support booting from a GPT partition, while 32 bit version do not support it until Windows 8, and from Windows 8 (32 and 64 bit) UEFI is required for booting the system. Wikipedia provides a nice overview in multiple tables 🗄️.
When using drives larger than 2TB, you should also use GPT.
Thus, unless working with some old or particular devices, there seem to be no reason to choose MBR over UEFI. I guess that for some devices like USB stick, it might makes sense to use MBR, so that they can still be used with from with PCs and operating systems.
Some sites suggest using gdisk/cgdisk/sgdisk when dealing with GPT partitions, but in the meantime fdisk supports those too:
fdisk is a dialog-driven program for creation and manipulation of partition tables. It understands GPT, MBR, Sun, SGI and BSD partition tables.
Thus unless working with older tools, there seem to be no reason except than personal preferences for switching between tools.
Primary and extended partitions
Extended partitions are only relevant when using MBR, as they are a workaround for having more than 4 partitions on a single drive. GPT supports many more partitions, thus there is little reason to restort to them.
Sector sizes
Check that your NVMe drives and Advanced Format hard disk drives are using the optimal logical sector size before partitioning. Consider performing SSD memory cell clearing before partitioning an SSD.
And there is a whole article about changing sector sizes 🗄️.
Partition alignments
Do tools from the command line handle partition alignment manually, or does noe need to do it manually?
fdisk, cfdisk, and sfdisk handle alignment automatically. gdisk and cgdisk handle alignment automatically. sgdisk by default only aligns the start of partitions. Use the -I/--align-end option to additionally enable partition size/end alignment. Parted only aligns the start of the partition, but not the size/end. When creating partitions, make sure to specify the partition end in mebibytes or a larger IEC binary unit.
Thus alignment, especially when using fdisk/cfdisk/sfdisk should not be an issue, making the commands used by KDE Partition Manager more portable between devices.
The fact that parted only aligns the stat, but not the size/end is not nice. On parted, I also found the following note:
Since many partitioning systems have complicated constraints, Parted will usually do something slightly different from what you asked. (For example, create a partition starting at 10.352Mb, not 10.4Mb) If the calculated values differ too much, Parted will ask you for confirmation.
parted and partition alignment 🗄️ At that point I wanted to see if my drives where aligned, since I formatted them a long time ago; it seems that fdisk does not provide that information, but parted does:
GNU Parted 3.6
Using /dev/sda1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) align-check opt 1
1 alignedFailed attempt to fix alignment
From the KDE Partition Manager logs, I noticed following warning:
2025-03-31 20:30:49: Partition '/dev/sda1' is not properly aligned (last sector: 1.953.525.134, modulo: 1.423).Imagine how surprised I was to read that!
Unfortunately, the misalignment is not shown by KDE Partition Manager by default 🗄️, one has to click on the menu and let it show the logs; I just found it out by accident.
Since I could not see from the log message if the alignment was really wrong, I’ve used the suggested script 🗄️ (yes, I’ve read the script before executing it) to print some more information, this is what I got:
what does the parted utility say about /dev/sda partitions alignment?
1 aligned
OK, seems to be all right, but...
let's check manually alignment to 4096B (necessary in case of SSD HDD):
Number Start End Size File system Name Flags
1 1048576 % 4096 = 0 1000204869119(+1) % 4096 = 3584 1000203820544 % 4096 = 3584
WARNING: not divisible by 4096*:
1 1048576 % 4096 = 0 1000204869119(+1) % 4096 = 3584 1000203820544 % 4096 = 3584
* on color terminals printed in color
INFO: why this might be a problem? https://superuser.com/questions/393914/what-is-partition-alignment-and-why-whould-i-need-itI’m pretty sure I formatted this drive years ago with GParted, but who knows anymore?
Is it bad?
At least the drive works, from what I’ve understood unaligned partitions might cause performance issues 🗄️, and unnecessary read/writes, thus reduce the life-span of the drive.
The easiest solution would be to delete and recreate the partition, at least it is not the partition where the system is installed.
Some sources suggest to use the option in KDE Partition Manager (or GParted) for resizing and moving partitions.
Thus, even with graphical tools, it seems my drive was no formatted "correctly", I wish I knew how it happened in order to avoid the same error in the future.
I also wish that more tools would trigger warnings by default, and that parted would not report a partition as aligned if the size/end is not aligned.
Thus I openend the option for resizing and moving partitions.
| Warning ⚠️ | Do a backup before trying to modify (move, resize, …) a partition. |
I clicked on advanced properties, as I wanted to be sure that KDE Partition Manager would align the partition.
At that point I noticed that the UI was in an inconsistent state 🗄️.
KDE Partition Manager reported as "first sector" the value 2048, and as "last sector" the value 1953525134. Toggling the checkbox "align partition" twice (thus disabling and enabling) changed the value of "last sector" to 1953523711, which is a valid value for an aligned partition.
This is the output I got after applying the operation:
Shrink partition '/dev/sda1' from 1,00 TB to 1,00 TB
Job: Check file system on partition '/dev/sda1'
Command: e2fsck -f -y -v /dev/sda1
Check file system on partition '/dev/sda1': Success
Job: Resize file system on partition '/dev/sda1' to 1.953.521.664 sectors
The file system on partition '/dev/sda1' already has the requested length of 1.953.521.664 sectors.
Resize file system on partition '/dev/sda1' to 1.953.521.664 sectors: Success
Job: Set geometry of partition '/dev/sda1': Start sector: 2.048, length: 1.953.521.664
Command: sfdisk --force /dev/sda -N 1
Set geometry of partition '/dev/sda1': Start sector: 2.048, length: 1.953.521.664: Success
Job: Check file system on partition '/dev/sda1'
Command: e2fsck -f -y -v /dev/sda1
Check file system on partition '/dev/sda1': Error
Checking partition '/dev/sda1' after resize/move failed.
Shrink partition '/dev/sda1' from 1,00 TB to 1,00 TB: ErrorIt looks like KDE Partition Manager did something wrong; and only not becase e2fsck -f -y -v /dev/sda1 reports an error, but because it says that "'/dev/sda1' already has the requested length", while it should have tried to change the length from 1953523087 to 1953521664.
I have not enough expertise to be able to say if the used commands are correct, but my guess is that KDE Partition Manager did not resize the filesystem before resizing the partition, because it looks like the file system already had the correct size. It is also strange that there are not details about the reported error.
So, what’s the actual status of my drive? KDE Partition Manager does not report any partition as unaligned; good. KDE Partition Manager reports an error on the filesystem; very bad.
I tried the option for cheking and repairing the file systems, but it just tells me that there is an error.
Check and repair partition '/dev/sda1' (1,00 TB, ext4)
Job: Check file system on partition '/dev/sda1'
Command: e2fsck -f -y -v /dev/sda1
Check file system on partition '/dev/sda1': Error
Check and repair partition '/dev/sda1' (1,00 TB, ext4): ErrorI tried running the same e2fsck manually, and see if it really does not tell what is wrong:
e2fsck 1.47.2 (1-Jan-2025)
The filesystem size (according to the superblock) is 244190385 blocks
The physical size of the device is 244190208 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yesAha, it seems that KDE Partition Manager does not show the output, and does not try to repair the partition 🗄️.
Let’s try to remove the -y parameter, and answer n instead of aborting.
e2fsck 1.47.2 (1-Jan-2025)
The filesystem size (according to the superblock) is 244190385 blocks
The physical size of the device is 244190208 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? n
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
127273 inodes used (0.21%, out of 61054976)
22153 non-contiguous files (17.4%)
107 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 125755/1508
210106788 blocks used (86.04%, out of 244190385)
0 bad blocks
18 large files
122187 regular files
5075 directories
0 character device files
0 block device files
0 fifos
0 links
2 symbolic links (1 fast symbolic link)
0 sockets
------------
127264 filesI’m not sure what to do with the output. Is the partition good now? Has it been repaired?
No, the partition still seems to be broken, as executing e2fsck again prints the same output.
I tried to use the option -p, but I was not lucky.
data: The filesystem size (according to the superblock) is 244190385 blocks
The physical size of the device is 244190208 blocks
Either the superblock or the partition table is likely to be corrupt!
data: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)At this point, as I was not sure how to continue, I decided to bite the bullet and remove and recreate the partition, as running fsck did not fix the issue.
Obviously I did a backup before trying to resize the partition, so no data was lost in the process.
Conclusion
I just wanted to format a drive on a remote machine, spent hours reading wiki pages and clicking links to new articles, and ended up reformatting a drive on my pc after failing at resizing it without errors and restoring the data from a backup.
While it was interesting, I really whish this would not be necessary. Especially because I’ve only covered partitions, on top of that on needs to choose a filesystem, some of which can be configured, and then there are also mount options.
Until now, I have not even tried in years to format a partition from the command line.
I really hope that graphical partition managers do the right thing™ and use the most appropriate settings.
But at least on the archlinux forum 🗄️ and 🗄️, it has been reported that the values used by GParted where suboptimal (I’m not blaming the tool, it might have been that it was not possible to programmatically query the correct values).
Following the rabbit a little bit made me also realize that the idea of executing KDE Partition Manager on a system and executing the same commands in another system, might not have been that good. The commands used on one system might give the wrong result, especially if the type of drive is not the same.
I guess I’ll have to pay more attention in the future when formatting a drive, in particular querying sector sizes, and ensuring that the resulting partitions are aligned correctly. Depending on how the drive is used, it might not make a big difference to use suboptimal values, but it can extend their lifetimes.
For new drives and devices (I guess new means the last 10 years), using GPT instead of MBR is the way to go, thus extended partitions can be completely avoided (and even when using MBR, they are only relevant if you plan to have more than four partitions on a drive).
And I’m very happy that there is no need to switch between so many tools (gdisk, fdisk, parted, …) and that they all (somehow) align partitions correctly (I guess they do not use the exact sector values but round to the nearest). Although I might want to avoid tools based on parted/gdisk as they do not seem to align the end automatically, in every case, it makes sense to verify indipendently that the partitions are aligned correctly.
Do you want to share your opinion? Or is there an error, some parts that are not clear enough?
You can contact me anytime.