Integrate full "4Kn" (4KiB) sector support in Garuda

Feedback Requests
1

The 4Kn logical block size in data-storage-hardware is advised to be supported in Linux since Kernel 2.6.31 since 9 September 2009.

4Kn industry standard is dated 2010 and the widely amount of manufacturer produce all data-carrier in 4Kib physical-block-size. Data-storage-hardware are delivered for consumer in 512e logical-block-size and for enterprise in 4Kn. Manufacturer who provide boot customer type provide a data-storage-controller able to switch between the block-size-dimension.

My request is to use modern tools for partitioning and formatting as explained in this post/thread and modify OS-installation as following:

  1. Detect physical and logical block size over script.
  2. Use gptfdisk-tools to partition, in the TUI (in Calamares) with cgdisk by "manual partition" and sgdisk for scripting-partitioning by "use entire disk".
  3. Use mkfs for formatting UEFI (EF00), Swap (8200) and Btrfs sitting on top of Ext4 (8300=Root), for "creating" ZFS (the future) should be allowed in Calamares just to use mounted partitions but the same must be aware of ZFS & Btrfs too.

Note-s:

  1. Detection of block-size, gptfdisk-tools and mkfs are mandatory. By the way, the developer of gdisk is also the developer of refind which is much better than grub.
  2. swap & btrfs are full supporting 4KiB, hence, there nothing to do.

Here the formatting commands with all necessary switches and options for the most used partitions-type under Linux:

  1. Formatting EFI-part in 4Kn/4KiB
mkfs.vfat -F32 -s 2 -S 4096 -v /dev/nvme0n1p1
  1. Formatting OS-part in 4Kn/4KiB
mkfs.ext4 -F -b 4096 -F /dev/nvme0n1p2
  1. Formatting SWAP-part in 4Kn/4KiB (again, this is not necessary, read swap-man-page)
mkswap -f -p 4096 /dev/nvme0n1p3

Finally, as you can see, if formatting ext4 is not used or necessary but only as partition-type for btrfs, the only problem remain is vfat that need exactly those parameter and options to work flawlessly.

Please take in consideration that 1 (one) 4096=4KiB data block take only place of 7x512 or 7x512e instead of 8x512 or 512e, hence, optimization of data-storage-hardware.

Consider please besides that the physical-block-size 4KiB is already an eternity on storage-device and soon all manufacturer will delivery device with only 4KiB=4Kn logical-block-size outer for pen-drives (USB-sticks) & SD-cards that will probably remain with 512 or 512e LBS.

Thanks you for your attention hoping you will consider my modification-request.

P.S.: Even Windoof already know about future delivery of storage-drives in 4Kn.

1 Like
2

I think all of those are rather unrealistic. I think this would need to be supported in kpmcore instead of writing some custom nonsense interactions with terminal tools.

4 Likes
3

Good grief, this looks like a repeat of your last topic. :man_facepalming:

Just to make it perfectly clear, you do not need to format your disk to complete the installation with Calamares. If you want to format your EFI partition a certain way, knock yourself out. You can even do it in the live environment, before the installer runs, with mkfs or gdisk or whatever you want.

When you are ready to run the installer, choose the manual partitioning option, mount the partitions, and do not format.

  • Manual partitioning

  • Select the EFI partition and click on Edit. Do not tick the format box.

EFI partition:

  • Content: Keep
  • Mount point: /boot/efi
  • Do the same for the Btrfs partition if you wish. Select the partition and click on Edit.

Btrfs partition:

  • Content: Keep
  • Mount point: /

Another lengthy discussion about what the default behavior of the partitioning tool the installer uses should be is unlikely to be productive. If you really see the need for a change, find the problematic code upstream and submit a pull request.

5 Likes
4

If <core/devicescanner.h> of kpmcore do recognize the differences between 512 and 4096 LBS and make the partitions or formatting these correctly… we have no point to discuss anymore but…

if don’t… you/we will feel it, sooner rather than later.

It is strange that you are not so much aiming at the solution of the problem or can you assure that the problem is solved with the tool you mentioned, but immediately criticize my well-considered choice of tools, but anyway…

Alright, I took a look at kpmcore in your place and the “Install.md” says it uses “util-linux” which in turn uses “sfdisk” and “partx” which are all scripts. So much for scripts!

So the developer of “kpmcore” is also the developer of “KDE partition manager” and this all tools having part in the name cannot or willnot work with 4Kn at all even after 14 years from declaration of standard.

Conclusion: All 4Kn storage have to be formatted manually also under Garuda and here and now I immediately lose any motivation to install it.

5

Thanks for answering first, I appreciate.

That’s absolutely right but please understand me too, I lose 12.5% of disk-space using 512e or 512 and now we know all the reason for that.

Thank you also for further explanations on your reply, this is also what I done until now and sorry for bothering you with my questions/request.

Of-course, this is an important problematic if also in Redmond are concerned about that, do you don’t mean? Especially if Linux has the claim to be an operating system for servers. Of course, this applies less to Garuda, but still important.

I would like to take your advice and make a pull request. Who or where can I address this to?

Thanks again and bye.

1 Like
6

No, that is not true. Perhaps this is all a simple misunderstanding.

A 4Kn drive may be more efficient in certain scenarios that benefit from larger sector sizes, such as handling larger files or improving disk performance for specific workloads. However, the difference in storage capacity between these drive types is negligible, as the overall capacity is determined by the number of sectors and the storage technology used, rather than the sector size itself.

With real-world data, if you had two completely full disks side-by-side, the difference in capacity would be most likely be between zero and a few bytes. The notion you would lose 12% of your disk space is absurd–that is just absolutely not true.

Keep in mind also we are talking about the EFI partition here. The installer defaults to giving you a 300 MB EFI partition. Of that, unless you are running Windows or switch to systemd-boot, you will probably use less than ten megs, with both Grub and rEFInd installed. Who cares about being able to potentially squeeze another few bytes on the partition if in actual use it is going to be mostly empty at all times?

This is absolutely, fundamentally, through-and-through a non-issue.

If certain disk maintenance tools you want to use do not handle formatting the way you think they should, you should address that with the developers or maintainers of those specific tools.

3 Likes
7

What do you mean exactly, if kpart is antiquate, I should contact his deleloper (from KDE) to use finally the Rodsmith Tools? I know some things I cannot write here, things that are really not conform to Linux-philosophy. Fact is, 4Kn standard since 2009 (14 years) not yet implemented completely.

This absolutely wrong because the size is different as well as the amount of clusters=for each 4KiB of data is an additional 512B sector necessary that cannot be fragmented in smaller “sector”. The only unknown “aspect” is, I don’t know how many files on standard Garuda installation is smaller than 4KiB.

Besides & for-all, with wrong formatting of EFI-partition through provided obsolete tools, the EFI is not able to be recognized at all and latest by reboot the OS cannot start. I saw OS-installation hanging at writing EFI on first partition, not only Arch-Script, Manjaro, Artix-Linux, Debian, Ubuntu, etc. PP. All have the same deficit not understanding 4Kn OotB.

The Topic is, no a matter which flavor, partition, file-system, operating-system… 512 & 512e are dead, switch to Rodsmith Tools and rEFInd as bootloader to get all problems solved at once included ZFS.

Out of the box or bubble where you/Garuda & Co. live is a world talking about RISC-V CPU’s (Canonical already provide experimental *ubuntu for that) with 128 bit as coming standard, ZFS also coming as standard (also already implemented by Canonical) and all these are point-release.

The rolling-release with top-notch kernels supporting newest hardware with all blin-blin and click-mich call the 4Kn-data-carriers unsupported Hardware after 14 years, that by standard installation with provided calamares fails to install or reboot. Find the failure!

If nobody of the responsible for any Distro don’t do or say anything… nothing will change, never.

Well, this is my last post about 4Kn, I will not disturb you or any else for this anymore, it’s up to you to push the attention for this topic, I’m out of this box.

Enjoy!

Edit:
Thanks to exclude me from mentioned thread above.
Only one statement about unsupported hardware=4Kn-data-carrier:

You can move the thread as many times and everywhere as you want but the statement that 4Kn is not supported hardware although the linux kernel since version 2.6.31 in September 2009 confirms the opposite, all this will not help you.

Imagine Linus Torwalds learns your statement :joy:.