Minimal partition sizes?
Please add the minimum sizes that are required to install Arch Linux distributions. (Does it vary much arch to arch?) I have installed Arch Linux ARM on the 512 MB flash of a Marvell Kirkwood SoC. Now I'm working with an Atom x86 system with 8GB to 16GB total storage. What are the minimum number (names) and sizes required for the O/S partitions? For my embedded systems, I usually separate the data partition from the O/S partition, and maybe I have a separate /var partition. But I do not typically have a separate /boot partition, and I try to make all but the data partition as small as possible.
- Needed size depends on what packages are you going to install: do you need base-devel, do you need X etc. My current setup with X, graphical web browsers, the whole base-devel group, python, python2 etc. takes up just 3 GB on / (I don't have a separate /var).
- The minimal required packages will vary depending on what filesystem do you have installed etc., but if you install just the base group and remove the packages you know you don't need (e.g. reiserfsprogs if you don't use reiserfs) you should have a lean setup. You shouldn't create too tight partitions, always try to provide enough headroom for some unexpected situations. -- Karol (talk) 22:56, 23 May 2013 (UTC)
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)
The information in this article does not match with the Solid State Drives#Partition Alignment. I am not an expert in this area, but my searching does lead me to think that this article is incorrect.
- I am adding a factual dispute flag to this section.
- I suggest removing the section's content and instead pointing it to the "SSD Partition Alignment" article and section.
- If there are engineers that still argue that alignment is necessary, perhaps that can be discussed under the very limited discussion that has taken place here: Talk:Solid State Drives#Alignment. --AdamT (Talk) 21:07, 17 November 2013 (UTC)
- I don't think the information is conflicting, but I'd say the title is/was inappropriate - IMO it's more like an introduction to data addressing on a disk. I think the best approach in this situation would be merging Solid State Drives#Partition Alignment into this page, generalizing also for HDDs (and especially for those with 4kiB sector size). -- Lahwaacz (talk) 21:53, 17 November 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.
- 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).