Talk:Partitioning
Partition Alignment Verification
[moved from Talk:Solid State Drives#Partition Alignment Verification -- Lahwaacz (talk) 20:13, 10 July 2014 (UTC)]
On my system 'blockdev --getalignoff /dev/sda5' returns zero, even though the partition seems not to be aligned optimally:
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors 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: 0xd9a92553 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 7 HPFS/NTFS/exFAT /dev/sda2 1026048 479475711 239224832 7 HPFS/NTFS/exFAT /dev/sda3 946051072 976771071 15360000 7 HPFS/NTFS/exFAT /dev/sda4 479475712 946051071 233287680 5 Extended /dev/sda5 479475775 518545791 19535008+ 83 Linux /dev/sda6 518545855 541984626 11719386 83 Linux /dev/sda7 541984690 557615871 7815591 82 Linux swap / Solaris /dev/sda8 557615935 946051071 194217568+ 83 Linux
The command 'parted /dev/sda align-check optimal' gives the right message in my opinion: 'not aligned'. Should we replace blockdev command?
Plk (talk) 18:31, 31 May 2014 (UTC)
- It seems you're right. After reading the warning about cfdisk alignment ("Warning: The first partition created by cfdisk starts at sector 63, instead of the usual 2048. This can lead to reduced performance on SSD and advanced format (4k sector) drives. It will cause problems with GRUB2, but GRUB legacy and Syslinux should work fine."), I created the first partition of the SSD I was working on with cfdisk - thus creating a bad alignment (I checked with fdisk -l /dev/sda, the first partition effectively starts at sector 63 and not 2048).
- The blockdev --getalignoff /dev/sda1 command returned zero (it shouldn't have) while your command parted /dev/sda align-check optimal returned 'not aligned', as expected.
- It seems to be a bug of blockdev in ArchLinux, as of util-linux v.2.24.
- I upgraded to util-linux v.2.25-3, and the problem is still present in blockdev. However, cfdisk has been entirely rewritten for util-linux 2.25 as described in this blog post and now correctly starts the first partition at sector 2048 when creating it.
- So should we edit the wiki page for recommanding upgrade to util-linux 2.25 in order to use cfdisk with correct partition alignment ? As util-linux integrates multiple essential softwares, I don't know if upgrading it will or not break something with the other utilities it includes.
- In any case, I think we should disrecommend using blockdev to check partition alignment, and recommend using parted instead for the time being. Can anyone else confirm this bug, especially on other distributions ? We need to know if the problem is inherent to Arch's implementation of blockdev or to blockdev itself.
Restructuring
Example tables
[1] moved tables from the Beginners' guide to Partitioning#Partition_scheme, however it didn't fit in too well so I've removed it for now.
However, I think the basic idea is a sound one, but perhaps more expansive. We could include suggested File systems, as well as more complex examples such as /var and GRUB Boot partitions.
See the updated tables from the BG below for reference. -- Alad (talk) 00:20, 10 July 2016 (UTC)
Table draft
| UEFI/GPT example layout | ||||
|---|---|---|---|---|
| Mount point | Partition | Partition type (GUID) | Bootable flag | Suggested size |
| /boot | /dev/sdx1 | EFI System Partition | Yes | 260–512 MiB |
| [SWAP] | /dev/sdx2 | Linux swap | No | More than 512 MiB |
| / | /dev/sdx3 | Linux | No | Remainder of the device |
| MBR/BIOS example layout | ||||
| Mount point | Partition | Partition type | Bootable flag | Suggested size |
| [SWAP] | /dev/sdx1 | Linux swap | No | More than 512 MiB |
| / | /dev/sdx2 | Linux | Yes | Remainder of the device |
- I added these tables to the page. I also added one using a separate
/homesince I imagine that is the most common scenario. I think 3 examples could be enough, but I am open to more. -- Rdeckard (talk) 18:53, 11 October 2016 (UTC)
- Nice work. One thing I was considering is to have multiple small tables under the various partition sections (like /home), instead of a single large one. Thoughts? -- Alad (talk) 18:56, 13 October 2016 (UTC)
- edit: I noticed you already split the tables; that leaves whether it makes sense to have them under sections like Partitioning#.2Fhome rather than Partitioning#Example layouts. -- Alad (talk) 19:01, 13 October 2016 (UTC)
Table draft 2
| Mount point on the installed system |
Partition | Partition type ID | Boot flag | Suggested size |
|---|---|---|---|---|
[SWAP]
|
/dev/sda1
|
82: Linux swap
|
No | More than 512 MiB or the size of RAM to use hibernation |
/
|
/dev/sda2
|
83: Linux
|
Yes | Remainder of the device |
| N/A | None | Unallocated space | N/A | At least 16.5 KiB |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
| None | /dev/sda1
|
21686148-6449-6E6F-744E-656564454649: BIOS boot partition
|
1 MiB | |
[SWAP]
|
/dev/sda2
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda3
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
Remainder of the device |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
[SWAP]
|
/dev/sda1
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda2
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
2: Legacy BIOS bootable
|
Remainder of the device |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
/efi
|
/dev/sda1
|
C12A7328-F81F-11D2-BA4B-00A0C93EC93B: EFI system partition
|
260 MiB | |
[SWAP]
|
/dev/sda2
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda3
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
Remainder of the device |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
/boot
|
/dev/sda1
|
C12A7328-F81F-11D2-BA4B-00A0C93EC93B: EFI system partition
|
260 MiB | |
[SWAP]
|
/dev/sda2
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda3
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
Remainder of the device |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
| None | /dev/sda1
|
21686148-6449-6E6F-744E-656564454649: BIOS boot partition
|
1 MiB | |
/efi
|
/dev/sda2
|
C12A7328-F81F-11D2-BA4B-00A0C93EC93B: EFI system partition
|
260 MiB | |
[SWAP]
|
/dev/sda3
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda4
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
Remainder of the device |
| Mount point on the installed system |
Partition | Partition type GUID | Partition attributes | Suggested size |
|---|---|---|---|---|
/boot
|
/dev/sda1
|
C12A7328-F81F-11D2-BA4B-00A0C93EC93B: EFI system partition
|
2: Legacy BIOS bootable
|
260 MiB |
[SWAP]
|
/dev/sda2
|
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux swap
|
More than 512 MiB or the size of RAM to use hibernation | |
/
|
/dev/sda3
|
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/)
|
Remainder of the device |
I didn't like the current Partitioning#Example layouts so I tried to make better ones, but I think I made too many of them. I'm not entirely certain if "GPT + BIOS & UEFI with Syslinux" is a good idea due to all of Syslinux's limitations, but GRUB doesn't use the "Legacy BIOS bootable" attribute and without the Syslinux example the whole column would become useless. Thoughts? -- nl6720 (talk) 10:19, 1 January 2018 (UTC)
- If syslinux needs special mention in a manner that is exclusive to it, then I'd argue that the column is useless anyway except to draw attention to syslinux. It seems like a Note would be better for that, assuming we want to recommend syslinux at all. -- Eschwartz (talk) 05:30, 9 December 2018 (UTC)
- It's not really Syslinux specific, theoretically the "Legacy BIOS bootable" attribute should be needed by any boot loader that puts stuff in the VBR (I wonder if that's also true for GRUB in VBR). -- nl6720 (talk) 09:06, 9 December 2018 (UTC)
- I think that's out of scope, if the user uses some bootloader which turns out to require a bootable flag, it's simple to go back into the ISO and set the flag accordingly. This is different from say, a BIOS Boot Partition (for GRUB) which would require actual changes in partitioning if not considered beforehand.
- As such I suggest to go with the following:
- -- Alad (talk) 20:35, 20 December 2018 (UTC)
mmcblk0p{1,2,3,4}, mmcblk0boot{0,1}, mmcblk0rpmb
And my install usb showed up as sda instead.. Don't know how to best deal with that. "Boot" ones don't seem to provide disklabel type and identifier information, and are only 4MiB. My guess is to ignore them. /dev/mmcblk0p3 seems to be the one with windows on it.(ASUS Vivobook E200HA)Jasper1984 (talk) 00:58, 25 December 2016 (UTC)
- Ended up just ignoring the
mmcblk0boot{0,1}entries, treatingmmcblk0p{1,2,3,4}as if were just sda, basically, it worked. (dont see the rpmb volumes now) More specifically, didnt reformat the first partition, instead just putting different files there. Tried the bind-mount approach in EFI System Partition, but ended up the more regular approach. (not sure why it didnt co-operate) Would suspect thatmmcblk0boot{0,1}dont matter much, but would suggest just reusing the first partition nevertheless..(really, little reason to reformat that?)Jasper1984 (talk) 00:34, 14 January 2017 (UTC)
Leaving unpartitioned space on a disk
From the following observations:
- in the future, you might want to use different partitions (test new OS, different FS, different boot partitions, creating a custom image, prototyping, ...)
- on big drives, most space usually remain unused (expect when storing games, a lot of videos/, other exotic usage)
- it is easier to expand a filesystem than to shrink it (some filesystem can't be shrinked)
My conclusion is that with big drives, the advice to leave unused space is correct for people with little to no experience with partitioning, Apollo22 (talk) 16:32, 15 June 2019 (UTC)
- This is so specific to user behaviour that you can't make a general recommendation like this. Most of the time, people have a reason to buy a large disk instead of a small disk, so telling them not to use the full capacity is rather silly. Also, a common paraphrase of the Moore's law says that no matter how large your hard drive is, in 2 years you will fill most of its capacity. -- Lahwaacz (talk) 18:11, 15 June 2019 (UTC)
- I disagree that that most people have a reason to buy a large disk because of the current price of disks. Also most people reading this part of the article have little experience, leaving some space free would give they the opportunity to move their data around to correct past mistakes without needing an external disk. Overall I think it's an important idea to include in the page, maybe more something to know about. For example: You might consider not partitioning your whole disk ? And give the reasons why ? -- Apollo22 (talk) 20:52, 15 June 2019 (UTC)
Wikipedia definition
I noticed that Device_file and File_systems both use Wikipedia to define their articles, but Partitioning did not. I took a look at the Wikipedia article for it, and it does seem suitable enough for this article, so I went ahead and wrote that in. I'm not sure what the consensus is on using Wikipedia as an "upstream" reference, but in this case, it fits well, I think.
My only concern is that the summary now neglects to differentiate block devices from hard disks, which a reader will only discover later in the article.
Wheatgold (talk) 15:54, 8 September 2020 (UTC)
Remove tool-MBR/GPT compatibility warning?
There is a warning in Partitioning#Partitioning_tools
Warning: ... use a partitioning tool compatible to the chosen type of partition table. Incompatible tools ... destruction of that table ....
In the table above the warning, MBR tools is already a _subset_ of GPT tools. Is it ok to remove the warning? —This unsigned comment is by PXf (talk) 15:21, 3 August 2021 (UTC). Please sign your posts with ~~~~!
- The only use I see for that warning is that if you open a device with a MBR partition table in gdisk, it will try to convert it to GPT. -- nl6720 (talk) 13:04, 4 August 2021 (UTC)
Verity and Verity Sign partition types and DPS
It seems this page should have some discussion of the verity partition types, and recommended partition layouts that include these partitions.
I'm still learning about these, and if/how they should be deployed, and came to the archwiki Patitioning page for information.
The many types of partitions available for GPT partition schemes are described here:
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
Some description of these features is given within this post:
https://0pointer.net/blog/fitting-everything-together.html
However it's a general description, and there is not concrete advice on how to deploy.
With archlinux's deep embrace of all things systemd, it seems this type of partition layout would be included.
—This unsigned comment is by Android (talk) 18:43, 28 December 2022. Please sign your posts with ~~~~!