Bug 1076963 - 9.14.5 Recommended Partition Scheme, outdated info
Summary: 9.14.5 Recommended Partition Scheme, outdated info
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora Documentation
Classification: Fedora
Component: install-guide
Version: devel
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Bokoc
QA Contact: Fedora Docs QA
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-16 19:47 UTC by Chris Murphy
Modified: 2014-12-16 17:13 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-16 17:13:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Chris Murphy 2014-03-16 19:47:32 UTC
Existing documentation with the problem is here:
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/s2-diskpartrecommend-x86.html

Here's a minimal list of problems and proposed changes for this page.


1. 9.14.5.1 recommends a layout the installer doesn't use by default. To fix it:
a. Change "partitions" to "mount points", to be consistent with newui terminology, and to apply to either partitions or LVs since the default is swap, root, home on LV, and only boot is on a partition.

2. The first NOTE, under "A /boot/ partition (500 MB)":
Let's just remove this. We haven't dealt with cylinders on drives for over 5 years, but rather Logical Block Addresses. I'm not sure what problem this is trying to solve, other than 2.2+TB drives in which case they need to be GPT and hope the BIOS doesn't puke. If it does, a separate /boot isn't going to fix it. Seems like very antiquated advice.

3. A root partition (3.0 GB - 5.0 GB)
Change to 3 GB to 20 GB to be consistent with the body text "full desktop installation, a minimum of 20GB for the root partition is recommended". Please also drop the insignificant digit

4. Side bar "Root and /root"
Both sentences are confusing, suggested rewrite:
The / mount point is the top of the Linux Filesystem Hierarchy, and is referred to as the root file system, or root.The /root directory, sometimes pronounced "slash-root", is the home directory for the root user.

*I consulted the v2.3 FHS to come up with this.

5. A home partition (at least 100 MB)
100MB is useless for gnome which is our default installation. Its indexer consumes 3GB for just one person. So if present, it needs to be a lot bigger than this or it should just be in /.


6. "To store user data separately from system data, create a dedicated partition within a volume group for the /home directory. This will enable you to upgrade or reinstall Fedora without erasing user data files."

This is really confusing because it conflates partitions and Logical Volumes in one sentence. Rewrite as follows:

"To store user data separately from system data, create a mount point for /home. This will enable you to reinstall Fedora without erasing user data."


7. "If you create many partitions instead of one large / partition, upgrades become easier."

This should be removed as it's based on partitioning mythology/religion, not fact. We even say separate /usr is proscribed. Fewer volumes to assemble is less complex which is easier, but so long as we can upgrade what we permit users to create, the "ease" of upgrading should be the same and if not then it's a bug. I'd just strike this whole sentence.

8. 9.14.5.1.1 Advice on partitions.
"Each kernel installed on your system requires approximately 220 MB on the /boot partition."

Untrue. On /boot, kernel 3.14 takes up 18.1MB total. That includes config*, initramfs*, System.map*, and vmlinuz*. Debug kernel with a generic non-host initramfs is 45MB. Even fully installed (to both /boot and /lib) is 141MB. This should be changed to "approximately 25MB" which leaves a bit of headroom for growing kernel sizes.

9. Find all instances of "partition" and make sure we mean partition (i.e. related to an entry in the MBR or GPT) and not either "mount point" or "volume". Partition is not a good generic term for applying to Logical Volumes and Btrfs subvolumes.

Comment 1 Chris Murphy 2014-03-16 19:48:14 UTC
See also https://bugzilla.redhat.com/show_bug.cgi?id=1045168#c69

Comment 2 Raman Gupta 2014-03-16 21:37:37 UTC
I don't know if it is worth documenting, but there is one situation according to my research in which a separate /var makes sense. That is, if the root filesystem is on an SSD, then /var, the contents of which change often, being a separate volume housed on spinning media saves wear and tear on the SSD. See for example:

https://wiki.debian.org/Multi%20HDD/SSD%20Partition%20Scheme

However, many people do mount /var on their SSD anyway -- the guidance in this area seems less than clear, but generally seems to be that for newer SSDs having /var on the SSD is not an issue.

Perhaps the documentation should just note this debate and let the user decide.

Comment 3 George Petasis 2014-04-22 10:13:52 UTC
Of course /var & /tmp should be away from any SSD.
I had a fedora 19 installation on a samsung 830, forgot to put /tmp & /var on separate partitions on traditional disks, and the 830 broke in about a year.
I had to replace the SSD.

The advise for /var & /tmp should be to be placed on traditional disks, if / is placed on an SSD.


Note You need to log in before you can comment on or make changes to this bug.