SOLVED? - Re: Command line for creating partitions

[Chris Murphy]

On Aug 8, 2014, at 4:29 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:

> I am learning how to use parted in command line format. Unfortuately there is no such command to delete all partitions, though you kind of can do it by changing the table type, say from msdos to gpt.
> 
> Also learned that the unused 4Mb I am seeing on most SD cards is for a reason.  To get on the 4Mb alignment for performance reasons.

It's 4KB, not 4MB, and it doesn't apply to SSDs, only HDD's specifically the 512e AF variety. a.) It's AF, Advanced Format, which means it has 4096 byte physical sectors, and 512e means it's emulating 512 byte sectors. So it appears as having 512 byte logical sectors, while having 4096 byte physical sectors. So one real sector has 8 logical sectors, which is where the performance problem can occur, when effectively asking the drive to update portions of a sector it causes the drive firmware to read-modify-write the sector.


> 
> parted /dev/sdb mkpart offset fat32 0 4

When I do that, parted complains.
"Warning: The resulting partition is not properly aligned for best performance."

What you should do is use 1 and 5, assuming you really want only a 4MB partition. In that case the result ends up being:

Number  Start  End     Size   File system  Name    Flags
 1      2048s  10239s  8192s               offset  msftdata

If you want to agree to the widely used convention, use LBA 2048 as the start. If you want to do your own thing, you could find out the erase block size for your SSD and align on those boundaries, but due to the non-transparency of the flash translation layer, there's no guarantee this means you're actually aligned on erase block boundaries: but it seems like a good idea, doesn't hurt anything, but might be a waste of effort depending on how things are actually implemented in the SSD.






> parted /dev/sdb mkpart uboot ext3 4 516
> 
> But it is still acting strange. Print is showing that ext3 partition fat32!

That's probably because libparted is finding a latent FAT32 superblock. The first thing to understand about parted, is that it's crusty. It used to do a lot of stuff that it doesn't do anymore but has the legacy operands of what it used to do. It used to format and resize volumes and partitions in one go, and it no longer does this. There is no partition type code that tells parted what the filesystem is, so it looks (maybe via libblkid, not sure) for the actual partition contents to see what filesystem it is and tells you that. But it's totally superfluous information in a partitioning tool. But in parted parlance you have to know these weird things because of its legacy. Likewise it doesn't directly tell you, or let you directly tell it, what a GPT partition's partition type GUID is. You have to tell it a filesystem, and then it sets the type code accordingly, which is quite honestly maddening. But whatever you just have to accept it if you're going to use parted. Its view of the world is abstracted to the degree it'll give you a completely distorted picture, and it's why I don't like it.

So your first command with fat32, doesn't actually cause the partition to be formatted fat32. It merely set the partition type GUID to EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data). Due to poor decision making, if you're using a Fedora 20 or older version, parted uses that same type code when specifying ext3 as the file system. Out of essentially unlimited UUIDs parted devs chose to usurp a Microsoft one. It baffles me whether I'm sober or drunk. The Fedora 21 version, parted will set an ext3 partition to partition type code 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) instead. And meanwhile gdisk and cgdisk have done this correctly for years.

The parted "File system" column is not a reflection of the partition type GUID, it's actually looking for filesystem superblocks to identify what the filesystem is.


Chris Murphy