SSD and partitioning (start sector)

[psyca]

Hello.
I want to ask which is the best setting for SSDs for the beginning/start sector. Some write its 2048 or something else. If i start the partitioning tool in MGA 8 it says "34" but i dont know why.
I think it would be usefull to start the partitioning tool in MGA with an "optimal setting" or "recommend setting" (like the 2048 or something else and not to default something which maybe doesnt make sense (or i dont understand why 34).

[doktor5000]

IIRC you can simply ignore that. diskdrake should align partitions on 2 MiB boundaries since ages: https://bugs.mageia.org/show_bug.cgi?id=1215

For your question about start sector 34, this is probably because you're doing an UEFI / GPT install: https://askubuntu.com/questions/199413/ ... d-use-enti

The size of the EFI label is usually 34 sectors, so partitions start at sector 34. This feature means that no partition can start at sector zero (0)

[psyca]

But wouldnt be 34 as start sector problematic, because you can not divide it with 8

See: https://debianforum.de/forum/viewtopic.php?t=179266 (german)

or 512 - https://rainbow.chard.org/2013/01/30/ho ... ng-parted/ (english)

[JoesCat]

For a mechanical harddrive, that maybe could be a good choice (64 would be the next value divided by 8).
For an SSD, there are no mechanical delays. Your biggest delays will probably be the writes, if you have large amounts of data to write that are larger than the SSDs internal queue (cache).

I would suggest separate partitions for '/', '/home', and maybe if you want to go further '/var', '/usr'
This way you can take advantage of paralleling calls - for example each partition has it's own journal if you use journalling file systems like ext4, and if you bork the drive, hopefully it is limited to one partition. This is another advantage with SSDs, no mechanical delays, and the internal circuitry is tuned for better parallel I/O.

[doktor5000]

But wouldnt be 34 as start sector problematic

No, because the alignment is added on top AFAIR.

[filip]

For an SSD, there are no mechanical delays. Your biggest delays will probably be the writes, if you have large amounts of data to write that are larger than the SSDs internal queue (cache).

This is another advantage with SSDs, no mechanical delays, and the internal circuitry is tuned for better parallel I/O.

Don't forget slight increase of Write amplification if partitions are not aligned.

[JoesCat]

Don't forget slight increase of Write amplification if partitions are not aligned.

Okay, I see what you are concerned about.
Although true, you can relax, because the numbers are quite different than what you think they may be.

Looking at the screenshot you took, it looks like you are working with a 120GB SSD.
For these sizes of SSDs, some have units of 4K and some might have units of 16K.
When speaking of 4K, we really mean 4x1024 bytes == 4096bytes (0..4095)
and 16K really means 16x1024 bytes == 16384bytes (0..16383)
You can go looking up the technical spec for your drive, and it's maybe 4K.
This value is worth checking for optimizing your write lifetime for the SSD.

Now supposing, you chose a file system, that uses sectors of 512bytes (this would be a bad choice here).
On the plus side, you can squeeze 8 strips of 512 into a single 4096 sector. This means you can squeeze 8 tiny files in 4096bytes. On the bad side, if you write/update one of these files (within one 512byte strip), you have to update the entire 4096byte unit. This means you unnecessarily have to re-write 7 other files over again, and this contributes to unneeded writes and wear on your SSD. In summary, the SSD won't last as long. Now, if you choose a file system that uses 4096byte units, matching your SSD, you waste a lot more space (if it is full of tiny files), but it is also much better with larger files and reduces wear of the SSD.
Using a 2000byte long file with file system units of 512 as an example:
write bytes 0...511 would update the first 512bytes....but you also affect bytes 512....4095, which have to be written over.
write bytes 512...1023 would update the next 512bytes....but you also affect bytes 0..511 & 1024..4095, which have to be written over.
write bytes 1024...1535 would update the next 512bytes....but you also affect bytes 0..1023 & 1536..4095, which have to be written over again.
write bytes 1536...2000 would update the next 512bytes....but you also affect bytes 0..1535 & 2048..4095, which have to be written over again.
In summary...you overwrite one 4K unit of the SSD 4x, when it could be done in 1 write if you had chosen a number matching what the SSD has.

When working with actual mechanical harddrives, you would want to start/end partitions as complete cylinders.
With SSDs, the mechanical way of mapping is not important, you really want your drive to optimize file sectors according to what the SSD is built for. So with small SSDs it may be 4k segments, or 16K segments, while the huge drives may have larger segments. Read the drive specs.

When Mageia's partitioning tool suggests 34, it is likely 34MB, which is fine, it will be some large value like 34x1024x1024, which you can think of as 34x256x4096 (if the SSD is made of 4096byte units), or 34x64x16384 (if the SSD is made of 16k units).

Just select a file system for your SSD that uses 4K or 16K sized sectors. Read the spec for the drive about unit sizes.