11.3. 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
/home
, /opt
, and /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.
Stale BIOS RAID Metadata
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.
Warning
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/
For more information about managing RAID devices, refer to
man dmraid
and Chapter 17, Redundant Array of Independent Disks (RAID).
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.
DASD
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.