Many storage device and file system settings can only be configured at install time. Other settings, such as file system type, can only be modified up to a certain point without requiring a reformat. As such, it is prudent that you plan your storage configuration accordingly before installing Red Hat Enterprise Linux 7.
This chapter discusses several considerations when planning a storage configuration for your system. For actual installation instructions (including storage configuration during installation), refer to the Installation Guide provided by Red Hat.
10.1. Special Considerations
This section enumerates several issues and factors to consider for specific storage configurations.
Separate Partitions for /home, /opt, /usr/local
If it is likely that you will upgrade your system in the future, place
/usr/local on a separate device. This will allow you to reformat the devices/file systems containing the operating system while preserving your user and application data.
DASD and zFCP Devices on IBM System Z
On the IBM System Z platform, DASD and zFCP devices are configured via the Channel Command Word (CCW) mechanism. CCW paths must be explicitly added to the system and then brought online. For DASD devices, this is simply means listing the device numbers (or device number ranges) as the
DASD= parameter at the boot command line or in a CMS configuration file.
For zFCP devices, you must list the device number, logical unit number (LUN), and world wide port name (WWPN). Once the zFCP device is initialized, it is mapped to a CCW path. The
FCP_x= lines on the boot command line (or in a CMS configuration file) allow you to specify this information for the installer.
Encrypting Block Devices Using LUKS
Formatting a block device for encryption using LUKS/
dm-crypt will destroy any existing formatting on that device. As such, you should decide which devices to encrypt (if any) before the new system's storage configuration is activated as part of the installation process.
Moving a disk from a system configured for firmware RAID without removing the RAID metadata from the disk can prevent Anaconda from correctly detecting the disk.
Removing/deleting RAID metadata from disk could potentially destroy any stored data. Red Hat recommends that you back up your data before proceeding.
To delete RAID metadata from the disk, use the following command:
dmraid -r -E /device/
iSCSI Detection and Configuration
For plug and play detection of iSCSI drives, configure them in the firmware of an iBFT boot-capable network interface card (NIC). CHAP authentication of iSCSI targets is supported during installation. However, iSNS discovery is not supported during installation.
FCoE Detection and Configuration
For plug and play detection of Fibre Channel over Ethernet (FCoE) drives, configure them in the firmware of an EDD boot-capable NIC.
Direct-access storage devices (DASD) cannot be added/configured during installation. Such devices are specified in the CMS configuration file.
Block Devices with DIF/DIX Enabled
DIF/DIX is a hardware checksum feature provided by certain SCSI host bus adapters and block devices. When DIF/DIX is enabled, errors will occur if the block device is used as a general-purpose block device. Buffered I/O or
mmap(2)-based I/O will not work reliably, as there are no interlocks in the buffered write path to prevent buffered data from being overwritten after the DIF/DIX checksum has been calculated.
This will cause the I/O to later fail with a checksum error. This problem is common to all block device (or file system-based) buffered I/O or
mmap(2) I/O, so it is not possible to work around these errors caused by overwrites.
As such, block devices with DIF/DIX enabled should only be used with applications that use
O_DIRECT. Such applications should use the raw block device. Alternatively, it is also safe to use the XFS file system on a DIF/DIX enabled block device, as long as only
O_DIRECT I/O is issued through the file system. XFS is the only file system that does not fall back to buffered I/O when doing certain allocation operations.
The responsibility for ensuring that the I/O data does not change after the DIF/DIX checksum has been computed always lies with the application, so only applications designed for use with
O_DIRECT I/O and DIF/DIX hardware should use DIF/DIX.