User:Zulu Foxtrott/Parts/Installation/Disks

Block devices
Let's take a good look at disk-oriented aspects of Gentoo Linux and Linux in general, including block devices, partitions, and Linux filesystems. Once the ins and outs of disks are understood, partitions and filesystems can be established for installation.

To begin, let's look at block devices. SCSI and Serial ATA drives are both labeled under device handles such as:, , {{Path|/dev/sdc}, etc. On more modern machines, PCI Express based NVMe solid state disks have device handles such as , , etc., while on embedded systems, SD cards and MMCs have handles such as , , etc.

The following table will help readers determine where to find a certain type of block device on the system:

The block devices above represent an abstract interface to the disk. User programs can use these block devices to interact with the disk without worrying about whether the drives are SATA, SCSI, or something else. The program can simply address the storage on the disk as a bunch of contiguous, randomly-accessible 4096-byte (4K) blocks.

Optional: Using LUKS to encrypt the main partition
Nowadays encrypting storage devices is widely regarded best practice to protect user data, for instance in case of theft or as a measurement against espionage or stalking. On Linux this is usually realized via the Linux Unified Key Setup (LUKS) on top of the kernel's dm-crypt disk encryption system. The application is the reference implementation of LUKS and is used to manage encrypted storage and associated passphrases and keys.

Encrypting the main partition will make the creation of an initial RAM file system (initramfs) later on in the installation process mandatory - otherwise the kernel won't be able to access the rootfs. Also, the kernel must be configured to support device encryption.

To encrypt the main partition of the default partitioning scheme use and specify the cipher to use with the command line argument   (the default), the keysize with   and the hash with. To ensure that instead of the legacy LUKS version the modern LUKS2 is used, pass the parameter.

TODO: correct output

This will ask for a password that in future can be used to unlock the encrypted partition.

Before a filesystem can be created on the newly encrypted partition, it needs to be unlocked. In the example it will be named  and thus afterwards be mapped to the device handle. Make the main partition accessible with:

At the password prompt, enter the password chosen before. If no error is shown the device should be unlocked now.

Introduction
Now that the partitions have been created, it is time to place a filesystem on them. In the next section the various file systems that Linux supports are described. Readers that already know which filesystem to use can continue with Applying a filesystem to a partition. The others should read on to learn about the available filesystems...

Filesystems
Linux supports several dozen filesystems, although many of them are only wise to deploy for specific purposes. Only certain filesystems may be found found stable on the architecture - it is advised to read up on the filesystems and their support state before selecting a more experimental one for important partitions.


 * btrfs
 * A next generation filesystem that provides many advanced features such as snapshotting, self-healing through checksums, transparent compression, subvolumes, and integrated RAID. Kernels prior to 5.4.y are not guaranteed to be safe to use with btrfs in production because fixes for serious issues are only present in the more recent releases of the LTS kernel branches. Filesystem corruption issues are common on older kernel branches, with anything older than 4.4.y being especially unsafe and prone to corruption. Corruption is more likely on older kernels (than 5.4.y) when compression is enabled. RAID 5/6 and quota groups unsafe on all versions of btrfs. Furthermore, btrfs can counter-intuitively fail filesystem operations with ENOSPC when df reports free space due to internal fragmentation (free space pinned by DATA + SYSTEM chunks, but needed in METADATA chunks). Additionally, a single 4K reference to a 128M extent inside btrfs can cause free space to be present, but unavailable for allocations. This can also cause btrfs to return ENOSPC when free space is reported by df. Installing and configuring the scripts to run periodically can help to reduce the possibility of ENOSPC issues by rebalancing btrfs, but it will not eliminate the risk of ENOSPC when free space is present. Some workloads will never hit ENOSPC while others will. If the risk of ENOSPC in production is unacceptable, you should use something else. If using btrfs, be certain to avoid configurations known to have issues. With the exception of ENOSPC, information on the issues present in btrfs in the latest kernel branches is available at the btrfs wiki status page.


 * ext2
 * This is the tried and true Linux filesystem but doesn't have metadata journaling, which means that routine ext2 filesystem checks at startup time can be quite time-consuming. There is now quite a selection of newer-generation journaled filesystems that can be checked for consistency very quickly and are thus generally preferred over their non-journaled counterparts. Journaled filesystems prevent long delays when the system is booted and the filesystem happens to be in an inconsistent state.


 * ext3
 * The journaled version of the ext2 filesystem, providing metadata journaling for fast recovery in addition to other enhanced journaling modes like full data and ordered data journaling. It uses an HTree index that enables high performance in almost all situations. In short, ext3 is a very good and reliable filesystem.


 * ext4
 * Initially created as a fork of ext3, ext4 brings new features, performance improvements, and removal of size limits with moderate changes to the on-disk format. It can span volumes up to 1 EB and with maximum file size of 16TB. Instead of the classic ext2/3 bitmap block allocation ext4 uses extents, which improve large file performance and reduce fragmentation. Ext4 also provides more sophisticated block allocation algorithms (delayed allocation and multiblock allocation) giving the filesystem driver more ways to optimize the layout of data on the disk. Ext4 is the recommended all-purpose all-platform filesystem.


 * f2fs
 * The Flash-Friendly File System was originally created by Samsung for the use with NAND flash memory. As of Q2, 2016, this filesystem is still considered immature, but it is a decent choice when installing Gentoo to microSD cards, USB drives, or other flash-based storage devices.


 * JFS
 * IBM's high-performance journaling filesystem. JFS is a light, fast, and reliable B+tree-based filesystem with good performance in various conditions.


 * ReiserFS
 * A B+tree-based journaled filesystem that has good overall performance, especially when dealing with many tiny files at the cost of more CPU cycles. ReiserFS version 3 is included in the mainline Linux kernel, but is not recommended to be used when initially installing a Gentoo system. Newer versions of the ReiserFS filesystem exist, however they require additional patching of the mainline kernel to be utilized.


 * XFS
 * A filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. XFS seems to be less forgiving to various hardware problems, but has been continuously upgraded to include modern features.


 * VFAT
 * Also known as FAT32, is supported by Linux but does not support standard UNIX permission settings. It is mostly used for interoperability with other operating systems (Microsoft Windows or Apple's OSX) but is also a necessity for some system bootloader firmware (like UEFI).


 * NTFS
 * This "New Technology" filesystem is the flagship filesystem of Microsoft Windows since Windows NT 3.1. Similar to vfat above it does not store UNIX permission settings or extended attributes necessary for BSD or Linux to function properly, therefore it should not be used as a root filesystem. It should only be used for interoperability with Microsoft Windows systems (note the emphasis on only).

When using ext2, ext3, or ext4 on a small partition (less than 8 GiB), then the file system must be created with the proper options to reserve enough inodes. The  application uses the "bytes-per-inode" setting to calculate the number of inodes for a file system. On smaller partitions, it is advised to increase the calculated number of inodes.

On ext2, ext3 and ext4, this can be done using one of the following commands, respectively:

This will generally quadruple the number of inodes for a given file system as its "bytes-per-inode" reduces from one every 16kB to one every 4kB. This can be tuned even further by providing the ratio:

Applying a filesystem to a partition
To create a filesystem on a partition or volume, there are user space utilities available for each possible filesystem. Click the filesystem's name in the table below for additional information on each filesystem:

For instance, to have TODO: what about those nowiki-tags (inherited from upstream handbook)?

To have the main partition in btrfs as used in the example partition structure, the following command would be used:

Alternatively, in case the main partition has been encrypted as outlined in the optional section above, use instead:

Now create the filesystems on the newly created partitions.

Creating Btrfs subvolumes
TODO: text

Alternatively, in case the main partition has been encrypted as outlined in the optional section above, use instead:

TODO: text

Mounting the subvolumes
Now that the partitions are initialized, are housing a filesystem, and subvolumes have been created, don't forget to create the necessary mount directories for every subvolume. Once this is done it is time to mount the subvolumes. Use the command followed by the command line parameter   to indicate that options are going to be passed to the command. The subvolume that is to be mounted can now be specified with the  option. As an example we mount the primary hierarchy root, the subvolume accommodating the rootfs:

Alternatively, in case the main partition has been encrypted as outlined in the optional section above, use instead:

Setting up the swapfile
As another example, in case it hasn't been done yet, create the mount directory for the subvolume that's going to host the swapfile:

Mount the respective subvolume:

Create an empty file that will serve as the swap space:

Adjust the permissions:

Disable copy-on-write (COW) for the swapfile:

As COW is disabled, it's necessary to define the size of the swapfile:

is the command that is used to initialize swapfiles (and swap partitions):

Create the swapfile with the commands mentioned above.

Alternative: no btrfs
TODO

Mounting the boot partition
The boot partition needs to be mounted, too:

Later in the instructions the proc filesystem (a virtual interface with the kernel) as well as other kernel pseudo-filesystems will be mounted. But first we install the Gentoo installation files.