We have a Btrfs Partitioning section, but it is not included in this article. Are we excluding Btrfs for now since it is still technically in development? I'd like to add a reference to the Btrfs Partitioning instructions at the very least. As a new user I went for the longest time thinking that GPT and MBR were my only options, but I much prefer using Btrfs exclusively if I can. I added a reference for Btrfs Partitioning and cleaned up some of the wording in those instructions. Dwightjl (talk) 06:38, 24 October 2013 (UTC)
- Well done, I think it's better to just link to the specific articles from here instead of directly including full instructions. For example also all the detailed information on MBR and GPT should be merged to the respective articles and replaced with simple links here, to reduce duplication of content. -- Kynikos (talk) 14:33, 25 October 2013 (UTC)
Information re. EBS removed
While I agree that some of the content removed was extraneous, I don't think this applies to the paragraph which explained why 512 was probably a safe default if you can't find out the EBS for your particular model. I'm not sure why this was removed as "extraneous information" seems an odd description for this particular content. --cfr (talk) 03:52, 30 November 2013 (UTC)
- Hey cfr, I am fighting a cold at the moment, so this may come off as abrupt, but here is my reasoning:
- See (above): Talk:Partitioning#SSD_Alignment.3F
- See: SSD#Partition_Alignment
- The information was vague and unsubstantiated.
- Which SSDs have an EBS of 512?
- Which do not?
- Is this still accurate? (Nope)
- A passing note as to what Ubuntu or Windows does is not a reference or a valid argument.
- This is not the location where information regarding EBS should exist.
- Please note that I was at my Summary limit.
- Edit: Oh, and the importance of EBS alignment may have been played up to begin with. Hence, it was "extraneous." : )
- In brief, it was no longer accurate and was too broad and too vague even when it was written. It is a complex topic, a simple solution is not available even if it is enticing. Implying that there is a simple solution, a "one size fits all" is misleading to those that may not understand the complexities and need to be able to decide for themselves (in keeping with The Arch Way).
- Please let me know if I have not clarified in an adequate manner. For further reading on the topic there are some on-topic links on at the Solid_State_Drives#See_also section. Take care, AdamT (Talk) 05:28, 30 November 2013 (UTC) Edit: AdamT (Talk) 05:32, 30 November 2013 (UTC)
GPT boot partition
Shouldn't it be added in this point? I'm reading from the install page, it links right in the beginning to here, i partitioned the disk as I do usually. I continue reading the Install page, install base, configure several things, until it reaches the point i have to install GRUB... first thing the GRUB install page tells me: create a partition in the first portion of the disk... great. starting over :/
ironically i read all the GPT and followed the steps (as this is my 1st GPT install) and even read the warnings about booting from a BIOS mode, etc... but nowhere it mentions that 1M partition needed for GRUB
- There is a note about "BIOS boot partition" in Partitioning#Using_GPT_-_modern_method... -- Lahwaacz (talk) 09:40, 12 February 2014 (UTC)
fdisk vs. gdisk (util-linux vs. gptfdisk)
Since util-linux-v2.24.x, fdisk and cfdisk support GPT. Therefore, we cannot continue to refer to (c)gdisk as GPT versions of (c)fdisk and, perhaps, an "Fdisk usage summary" subsection inclusion at the "Using GPT - modern method" or an adaptation of the "Gdisk usage summary" should be worth. I believe people is more familiar with fdisk and, moreover, it seems to better recognize the GPT partition types. Besides, I wonder on the interest of including gptfdisk as part of the ArchLinux install environment. CedricMC (talk) 16:26, 18 February 2014 (UTC)
- Beware of this objection. The blog post you linked is from September 27, which predates Keshav Padram Amburay's objection, is it already stable? -- Lahwaacz (talk) 16:57, 18 February 2014 (UTC)
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?
- 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.
Recommended partition sizes
The values specified on the page seem to be somewhat obsolete. I experienced problems because I didn't create swap. Since the wiki suggested so. Also, I now have ~300M left on my var partition. Which is 12G in size. x-yuri (talk) 20:47, 30 November 2014 (UTC)
- Obviously the amount of RAM necessary for "good performance" highly depends on the purpose of the system, tasks such as editing (HD) videos, running virtual machines or even compiling software using template libraries with GCC are very memory demanding. But creating swap will not solve the performance problem, the only way to solve the problem is to get more RAM.
- As for the obsolescence of the values, surely we can't apply the Moore's law and multiply the recommended values by the factor of 2 each year. Also I don't think we can artificially recommend higher values for just one case in hundreds/many. But if you feel there is a way to improve the section preserving generality, feel free to update it.
- -- Lahwaacz (talk) 21:19, 1 December 2014 (UTC)
remove gdisk instructions for install medium 2013-11
[Moved from Talk:Beginners' guide#remove gdisk instructions for install medium 2013-11. -- Kynikos (talk) 10:14, 29 December 2014 (UTC)]
fdisk now has GPT support, this means that both MBR and GPT disks can now be formatted with
fdisk. Does anyone object to removing
gdisk instructions from this guide when the new image is released?
--Lonaowna (talk) 09:34, 25 October 2013 (UTC)
- No, I strongly object. util-linux fdisk's GPT support is beta/experimental and it does not offer full set of GPT manipulation features that gdisk supports. And Rod Smith (srs5694) does an amazing job of maintaining gdisk upstream and also helps users in the forums and contributes to the wiki. You can maybe add info about util-linux fdisk's GPT support, but alone with mentioning clearly its limitations viz-a-viz gdisk. Even if fdisk gains full GPT support, gdisk is not going anywhere and its more mature. -- Keshav Padram Amburay (talk) 09:51, 25 October 2013 (UTC)
- Okay, I thought it was classified as 'stable' now, but if it isn't, we should indeed keep gdisk. In the future however, I would like to move to a one-partioner because it would be a lot cleaner (the current 'partitioning' section is a mess). Thanks for the reply! --Lonaowna (talk) 06:38, 27 October 2013 (UTC)
- Well, there have been a few stable util-linux releases, and the current
man fdisksays "GPT is always a better choice than MBR (...)". I could not find any information that says it is in "beta" or is "unstable" or "experimental". To be honest however, I have not been partitioning myself that much lately, so I can't say first hand that it is "as good as gdisk", or "bug-free'.
- It might be a good idea to ask around in the mailing list. Hopefully there are some experts there that could have a say in the matter. If there isn't any resistance there, I would say: switch the instructions to fdisk, and if there are any issues that come up from new users, we can always revert. Lonaowna (talk) 18:53, 30 November 2014 (UTC)
- Well, there have been a few stable util-linux releases, and the current
- The cg/fdisk examples have been moved to this article from the Beginners' guide. The fdisk example may be deleted as discussed above; the cgdisk may be adapted if considered useful. However I also propose to move all the g/fdisk examples to a separate fdisk article. -- Kynikos (talk) 10:21, 29 December 2014 (UTC)
- I've just split fdisk. Talk:Beginners'_guide#Replace_parted_with_cfdisk.2Fcgdisk is a related discussion. — Kynikos (talk) 04:11, 29 July 2015 (UTC)
Not sure if this fits with the Arch wiki ethos, but I'd like to revise the Partitioning article to more clearly explain the principles behind it. I suspect the reason so many new users find this aspect so intimidating is because they don't understand what is really is or why it should be used. Another option is to create a separate "Partitioning Overview" article that the existing one can link to. I already have a lot of stuff written for a manual I'm putting together, but I think it would benefit more people on the Arch wiki. Carlduff (talk) 11:48, 13 March 2016 (UTC)
- Well, sure it is in the wiki's ethos to have a Partitioning article that is somewhat encompassing the whole flexibility and simplicity which is at the core of the distro. It is subjective, but in mine Partitioning itself is a great Overview article. Though, partitioning is not an area I am particularly active in, I have just observed a lot of contributions by many editors to improve Partitioning itself, the Beginners' guide#Prepare the storage devices, the recent Fdisk rework, etc. Can you perhaps focus one or two points what you would make different and open an item in Talk:Partitioning? I watch the article and will try to participate. --Indigo (talk) 17:29, 13 March 2016 (UTC)
- This article is already an "overview" one, so the idea of creating an overview of an overview can't be considered, or we'll be duplicating content and efforts.
- As Indigo says, it's better if you list here the details that you want to add more specifically, so that we understand your intentions.
- — Kynikos (talk) 04:05, 14 March 2016 (UTC)