Should partition sizes be powers of 2 ?

[Tony0945]

I'm going to move an old (but up to date) install from a 10,000 RPM 500G Velociraptor to a 1T SSD. The main Gentoo partition is 85% full and sometimes the drive light is on steady for quite a long time. I really plan to put all the extra space on the main Gentoo partition. The other partitions have plenty of space.

This is a BIOS boot machine. An old Gigabyte mobo that won't seem to boot a USB stick. /dev/sda is a damaged Windows drive that Neddyseagoon advised me to get out of the machine months ago. But it's still there. I don't have a spare DVD drive so my plan is this:

1. Format the drive on a different machine, one that I can boot my rescue media on.
2. Copy the files on partitions via rsync. Their are four bootable partitions, so I'll rsync a live partition on which data may be changing.

Old partition layout:

• /dev/sdb1 980M mounted as /boot (primary boot)
  /dev/sdb2 1.9G mounted as swap
  /dev/sdb3 217G mounted as /
  /dev/sdb4 246G BIOS extended partition
  /dev/sdb5 64G bootable 32-bit Gentoo partition used as build box for ancient k6 machine
  /dev/sdb6 36G bootable (chain loaded) Ubuntu installation
  /dev/sdb7 145G bootable (chain loaded) Gentoo rescue partition, mid-December 2020 stage3 plus Mate & utils, no overlay code vanilla Gentoo

Proposed new layout as primary disk, pulling the Windows disk

• /dev/sda1 ~720G mounted as / , no separate boot, using a swapfile or perhaps a swap on /dev/sdc (which will become sdb)
  /dev/sda2 64G 32-bit Gentoo
  /dev/sda3 36G Ubuntu
  /dev/sda4 ~145G Gentoo rescue partition

I don't propose to change the 32-bit or Ubuntu partitions. I will have to chroot into them and re-run grub-install on the partition, also the rescue partition.
Then chroot into main Gentoo and run grub-install into the MBR.

Since /boot/grub/grub/grub.conf will now be on a main live partition, this will be less safe as a bad partition error will render all unbootable, unless I remove the drive and stick it in another machine for repair.

Lot's if's, but's, and maybe's here, but my main question is about the partition sizes.

[NeddySeagoon]

Tony0945,

On an SSD, which will have a 4kB physical block size, with 512B blocks faked, partitions need to start on a 4k boundary.
If you know the erase block size, erase block boundaries are better but its usually very difficult to discover and it won't matter much.

Just like the concept of real CHS addresses for rotating rust was abstracted away by logical block addressing when drives reached about 2GB (late 1990's) so SSDs abstract away the concept of a partition being a sequential collection of blocks. SSDs have a layer of indirection at the erase block level to implement wear levelling, so you never know where your data is physically located.
This abstraction layer was started in HDD, when spare sectors and spare tracks were introduced to hide manufacturing defects and through life sector/track failures.

I'm fairly sure that current fdisk and parted use 4kB block alignment by default but if if you want to check (trust but verify), Have fdisk show you the partitions using sector numbers.
Start sectors should be an integer multiple of 8.

As you have several Linux installs, use one to copy all the others except itself. Reboot into a different install and copy over the last install.
There is no need to do any copying from a live filesystem.

[Tony0945]

I really screwed up partitioning a decade or so ago:

Code: Select all

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdb1  *           63   2008124   2008062 980.5M 83 Linux
/dev/sdb2         2008125   6024374   4016250   1.9G 82 Linux swap / Solaris
/dev/sdb3         6024375 461290409 455266035 217.1G 83 Linux
/dev/sdb4       461291520 976773119 515481600 245.8G  5 Extended
/dev/sdb5       461293568 595802111 134508544  64.1G 83 Linux
/dev/sdb6       595804160 672143359  76339200  36.4G 83 Linux
/dev/sdb7       672145408 976773119 304627712 145.3G 83 Linux

Partition 1 does not start on physical sector boundary.
Partition 2 does not start on physical sector boundary.
Partition 3 does not start on physical sector boundary.

The first partition should start at 64 instead of 63, correct? The unpartitioned space would then be blocks 0 through 63 for 64 blocks of 512. Thereafter if I make the sizes all multiples of 4K, I should be OK? All partitions will now be ext4. Will that leave space for grub in the front of the partitions? It looks like I have 1M between partitions that have grub partition installs (chain loaded).

EDIT: Couldn't get warranty status or find when I bought it. Smartcontrol says the power on hours are 66195 which jibes with my feeling that it's about ten years old. It's been a good drive. Just old, like me. Unlike me, all the parts seem to be in good working condition.

[toralf]

FWIW all of my disk (HDD and SSD) starts with 2048 (not 63)

[NeddySeagoon]

Tony0945,

Sector 63, is CHS 0,1,0, honest. :)
Its where all the jiggery pokery to extend CHS address ended up and a decade ago was the default start sector for the first partition.

toralfs 2048 became standard with GPT, as the first copy af the partition table is in LBA 1..2047 or there abouts.
Its a really bad idea to start the first partition in the middle of the partition table. :)
To help fit the pieces together this is why grub2 require a small partition to itself with GPT in use. There is no unused space before the first partition.

Without knowing the physical block size of the drive in question, we can't tell if it matters. You didn't post that.
Actually, the drive model number from

Code: Select all

smartrctl -a /dev ...

would be better because drives often lie about the physical block size to operating systems.

[Tony0945]

LOL! Excellent. Excellent. What I posted was the Velociraptor to be put to pasture (my spare drive shelf).

The Black Friday drive I intend to use is Crucial model CT1000MX500SSD1 1000GB assembled in Mexico but there are no Spanish markings. The front has lots of Chinese characters. I'll probably have to update firmware. I might even have right firmware on my Ryzen workstation. Unlike my previous Crucial MX500 purchase there are no instructions in the package. Maybe it's all that Chinese writing. I also have a Samsung but that's for a different build.

[NeddySeagoon]

Tony0945,

When you partition it, both fdisk and parted will do it right.
If you are not using GPT and will never want to do in an place conversion to GPT, its safe to start the first partition at LBA 64.
The difference is less than 1MB, so its not worth the effort.

As I said, trust but verify.

[Tony0945]

If you are not using GPT and will never want to do in an place conversion to GPT, its safe to start the first partition at LBA 64.
The difference is less than 1MB, so its not worth the effort.

No, I won't. In a few months I'll clone it to an NVME Ryzen 3 UEFI build. After that, I'll probably not use it much.

Based on the rest of the thread, I was thinking of the first partition at 1MB and IMB between partitions. That's 4MB wasted out of 1,000,000 MB. A drop in the bucket.
But, if I read the thread correctly, the partitions should be on 1MB divisions and of the approximate size that I indicated.

That is, if there isn't something in ext4 that affects this. Isn't an inode 4K, so the sizes should be an integer multiple of 4k?

[NeddySeagoon]

Tony0945,

An i-node is 128B or 256B. 256B is standard today.
ext4 will use a 1k, 2k or 4k block size, depending on the size of the filesystem.

There is no need to have gaps between partitions.
UEFI is GPT only, so you can copy the filesystems over.

Starting partitions on 4k boundaries is all that's needed, with a start at 1MiB, or LBA 2048

[Tony0945]

Got it! Assuming there is enough room for Grub2 on partition boot partitions. Does grub use unused space at the beginning of the partition? Or before the partition?

[NeddySeagoon]

Tony0945,

I wrote this wiki page so that the handbook could be simplified.
Does that help ?

[Tony0945]

I wrote this wiki page so that the handbook could be simplified.
Does that help ?

Yes, indeed, that must have taken a long time to assemble and proof check. Thank you very much!

The way is clear, as for the individual partition sizes, I think making them whole numbers of MB will be sufficient. I'm still not quite sure of partition booting, so I'll google some more. I think it's not required and the default 2048 sectors of MBR should be more than sufficient for grub in the MBR.
I will use MBR rather than GPT because it's an old old system that doesn't support UEFI and the disk size at 1TB is well under 2TB.

I failed to mention that the system has a third drive, a 2TB WD Black with one big NTFS partition. It's purpose is video storage. it's NTFS because originally it was used by XP only. I was thinking of creating the partitions and copying files over wired ethernet from another PC, but I think a better idea is to temporarily remove the third drive and put the SSD there temporarily. Then the file transfers will be by SATA from 10,000 RPM HDD to SSD on the same system. should be the fastest way to transfer. I'll have to then remove the SSD, put it one of the PC's that can boot DVD or USB, fire up the rescue medium, very that the drive is in the first position and run the grub-installs from there. Then bring it back to the orginal system, remove the bad Windows disk and the Velociraptor leaving a two disk system of SSD and 2TB dta drive. /dev/sda and /dev/sdb respectively. Oh, and /etc/fstab will have to be modified because the PART_UUID's will be different.

If only my system would boot the USB stick, I could have just removed sda, booted the USB, re-installed the grub's, and be done. Ah! No challenge, eh?

[figueroa]

FWIW, I have an old but large drive in my 32 bit Gentoo machine where sda1 starts at 63 and I don't get any grief from fdisk. I'm sure I didn't pick 63 on purpose:

Code: Select all

Disk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WD5000AAKS-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000d529d

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *           63 209712509 209712447   100G 83 Linux
/dev/sda2       209717248 419432447 209715200   100G 83 Linux
/dev/sda3       419432448 629147647 209715200   100G 83 Linux
/dev/sda4       629147648 976773167 347625520 165.8G  5 Extended
/dev/sda5       629149696 723521535  94371840    45G 83 Linux
/dev/sda6       723523584 817895423  94371840    45G 83 Linux
/dev/sda7       817897472 912269311  94371840    45G 83 Linux
/dev/sda8       912271360 976773167  64501808  30.8G 83 Linux

All the hardware is at least 10 years old. Am I doomed?

[NeddySeagoon]

figueroa,

The data sheet for your WDC WD5000AAKS says nothing about it being an Advanced Format drive, so its probably not.
That means any sector boundary works for you.

[figueroa]

figueroa,

The data sheet for your WDC WD5000AAKS says nothing about it being an Advanced Format drive, so its probably not.
That means any sector boundary works for you.

Thank you for that. The Advanced Format reference/link is jewel.

[Hu]

For a long time, 63 was a de facto standard. The Advanced Format drives interacted badly with it, to the point that some drives were wired to lie by adjusting the offsets you see/use by an increment that put things on the alignment they wanted. This caused its own problems, since then tools that tried to do the right thing (by aligning in software) would end up doing the wrong thing (by having the hardware misalign the boundary that the software got right). Of course, at least some of these lying drives had no provision for the software to query whether the drive would adjust alignment, so it was impossible for the software to do the right thing, even if its author knew all these rules. Fortunately, that's far enough in the past that current generation drives are a bit more sane.

[Tony0945]

All, hopefully this new Crucial MX500 SSD is sane.

[NeddySeagoon]

Tony0945'

All SSDs apart for a few very early ones, use 4kB blocks and to my knowledge, are sane.
However, many SSDs lie about the physic block size and fake 512B blocks.

Code: Select all

$ sudo fdisk -l /dev/sde
Password: 
Disk /dev/sde: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: Crucial_CT512MX1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 34FC1BD2-FEC6-4CEC-9A4E-0EF83A538F86

Device      Start        End   Sectors   Size Type
/dev/sde1    2048     249855    247808   121M Linux filesystem
/dev/sde2  249856 1000214527 999964672 476.8G Linux filesystem

That's honest,

Code: Select all

Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

it can fake 512B sectors but that should be avoided.

What does fdisk -l say about your MX500?
It think its the bigger brother of my SSD.

[Tony0945]

What does fdisk -l say about your MX500?

I haven't connected it yet. Been out all day. Bad weather predicted for the next two days.

But here is the 500GB version of the series:

Code: Select all

 ~ $ fdisk -l /dev/sda
Disk /dev/sda: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: CT500MX500SSD1  
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 3EE9432E-169D-4EC5-A9EC-7F932FBDCD61

Device      Start       End   Sectors   Size Type
/dev/sda1    2048    206847    204800   100M EFI System
/dev/sda2  206848 976773134 976566287 465.7G Linux filesystem

It's on my MSI B450 Ryzen system.
I see they still play games with the definition of G.

BTW, your earlier comment about parted applying changes right away is another reason to use gparted. Gparted saves all the changes including creating the filesystems and labels, you review them then pull the trigger or start over.

[NeddySeagoon]

Tony0945'

Code: Select all

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes 

Its really 4kB blocks but it can fake 512B blocks.

Use 4k alignment and you will be good.

I bought a 1TB SSD a few months ago to go in my arm64 build box but it has 128G RAM and everything is is RAM anyway, so I've not even broken the seal yet. It won't make it measurably faster.
Its a 1000GB Crucial MX500 :)

[Tony0945]

I bought a 1TB SSD a few months ago to go in my arm64 build box but it has 128G RAM and everything is is RAM anyway, so I've not even broken the seal yet. It won't make it measurably faster.
Its a 1000GB Crucial MX500

I'll be sure to run before and after "hdparm -tT". Despite my concern about the damaged Windows drive sending spurious SATA signals. Before is not bad, but remember it's a 10,000 RPM drive.

Code: Select all

 # hdparm -tT /dev/sdb3

/dev/sdb3:
 Timing cached reads:   6702 MB in  2.00 seconds = 3351.74 MB/sec
 Timing buffered disk reads: 548 MB in  3.01 seconds = 182.26 MB/sec

The 7200 RPM NTFS data drive:

Code: Select all

~ # hdparm -tT /dev/sdc1

/dev/sdc1:
 Timing cached reads:   6798 MB in  2.00 seconds = 3400.22 MB/sec
 Timing buffered disk reads: 432 MB in  3.01 seconds = 143.75 MB/sec

[Tony0945]

OK - to clarify the answers to some of my questions:

After a long google search starting with the excellent Wikipedia article on grub, I was led to https://ext4.wiki.kernel.org/index.php/ ... out#Layout
The grubb2 manual told me that on an MBR partition install grub.img (IIRC) is stored in the filesystem as /boot/grub.img and the disk location of that file is stored at the beginning of the partition. Although I couldn't find that file, the above link says:

For the special case of block group 0, the first 1024 bytes are unused, to allow for the installation of x86 boot sectors and other oddities. The superblock will start at offset 1024 bytes,

Together they mean that no inter-partition space is used or needed. It's not that I doubted you, NeddySeagoon, it's just that I needed to understand the "why" of your statement that inter-partition space is not needed. It also means that on the new disk, the grub2 partition installs will have to reinstalled as the coordinates will certainly change. That can be done by chroot.
The 1024 sector offset after the MBR will obviously be sufficient for the grub-legacy MBR stage 1.5 install since 63 sectors were enough on the HDD.

Unanswered is, will I need the drive to be in the /dev/sda position to re-install grub-legacy. i think the answer is yes, and I will have to do that on a separate machine that can boot by CDROM or USB and support SATA . Fortunately, I have two handy. Copying SATA to SATA for the partition data (via cp NOT dd) should be faster than my original idea of using rsync with the new drive on a different machine.

We are facing four days of snow, so I should have time to do this without "honey do's".

EDIT: The grub link: https://www.gnu.org/software/grub/manua ... 02dinstall

4.4 BIOS installation
MBR
...or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition. Each of these has different problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing restrictions; and systems are sometimes partitioned without leaving enough space before the first partition.

Which explains why partition install is not recommended for grub2.

[NeddySeagoon]

Tony0945,

Unanswered is, will I need the drive to be in the /dev/sda position to re-install grub-legacy.

The real answer is maybe. :)

You need it in BIOS slot 0 to make life easy. Exactly what BIOS slot 0 translates to in kernel terms varies with BIOS, hence my maybe.
Some BIOSes set the boot drive to be slot 0. They are a PITA because your grub legacy install works then you change boot drives and booting fails because grub legacy is now installed on the wrong MBR.

Grub legacy uses BIOS drive ordering not kernel ordering.

[Tony0945]

I think my BIOS is like that one. If I select the Gentoo drive from the BIOS boot menu, grub starts and then rapidly scrolls an error message about not finding stage 1.5. Gigabyte GA-880GA-UD3H, BIOS FF 03/07/2011
FF being the latest BIOS.

Otherwise I could have just removed the Windows drive and booted? Oh Wow!

I found many references to Gigabyte not booting USB sticks. Often it is said you need USB 1.0 even though later USB's are supposed to be compatible.
Also a at least two notes that the stick can't be bigger than 6G. The BIOS doesn't offer a plain USB boot option, only USB-floppy and USB-Disk. Neither finds bootable media. My stick works fine on the later Gigabyte board in the basement and my MSI board, both of which are new enough to be UEFI.
I did try this procedure and the stick was shown, but selecting it resulted in "not a bootable disk", which is not true. If only my CD drive hadn't gone south. Old sysrescuecd was a trusty boot medium for this board.

So, I'm doing this high wire dance. Yesterday I rummaged through the junk pile I call a desk downstairs looking for my two blue powder coat 2.5 to 3.5 adapters. I did find a black one i didn't even know I had. I'll try using it.

[figueroa]

I have a 2009, Gigabyte MA78GM-US2H that boots from USB or even the secondary hard drive. Have you updated BIOS? My suggestion is install grub to SDB. When you swap drive position, edit your menu list appropriately as needed. And, if necessary, reinstall GRUB.