2.6. Physical Storage

Read this section for a summary of changes to support for physical storage and relevant configuration tools between Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7.

2.6.1. Changed mount behavior at boot

If a storage device is configured to mount at boot time, and that device cannot be found, or does not mount correctly, Red Hat Enterprise Linux 7 fails to boot. This is an intentional change of behavior to prevent systems from booting without important storage devices. Earlier versions of Red Hat Enterprise Linux booted regardless of whether all storage devices that were configured to mount at boot were found or mounted correctly.
If a device should not prevent the system from booting, you can mark it with the nofail option, as shown.
/dev/essential-disk			/essential			xfs	auto,defaults				0 0
/dev/non-essential-disk		/non-essential		xfs	auto,defaults,nofail		0 0

2.6.2. Using LVM snapshots as a rollback mechanism


LVM snapshots are not recommended as a primary rollback method. During an upgrade, the entire system (except user files) is overwritten. A snapshot of the system is therefore nearly the same size as the original data set.
Additionally, snapshots are more prone to error than the typical backup process, as they do not include the /boot partition.
When upgrading from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7, Red Hat recommends taking a full backup and using the backup as the primary rollback method. LVM snapshots should be used as a secondary rollback method only.
As of Red Hat Enterprise Linux 6.3, users can reserve space on their logical volumes to use as storage space for snapshots. The system can then be rolled back to the snapshot in the event that an upgrade or migration fails.
If you want to use an LVM snapshot as a secondary rollback method, you may need to add space to allow room for a complete snapshot. To add more space, you can do any of the following:
  • Add another disk. Instructions can be found in the Red Hat Enterprise Linux 7 Storage Administration Guide, available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
  • Use parted to check for free space that is not allocated to an existing partition.
  • Use lsblk to check for empty partitions, or partitions that can be deleted to free space.
  • Use vgdisplay to check for free space in a volume group that is not allocated to a logical volume.
  • Use df to check for file systems that have free space and can be reduced, so that their logical volume or partition can be shrunk to free space.
Be aware of the following potential limitations of using LVM snapshots for rollback:
  • Snapshot size is not adjusted automatically. If your snapshot gets too large for its partition, it may become invalid, and rollback will fail. It is therefore imperative to allocate a sufficiently large space for a snapshot of your entire system, before creating that snapshot. If you need to resize a root snapshot, you will need an additional device such as a Live CD that can be used as a root device while your original root device is unmounted and resized.
  • The copy-on-write device of a snapshot is not mirrored, and will be on a single device regardless of whether your system is mirrored. If the device fails and you lose the snapshot, rollback is impossible. Red Hat recommends using a physical volume with mdraid, or using multiple snapshots to separate disks. Using multiple snapshots is slower.
  • In the event of a crash during installation, the system can become impossible to boot. In this circumstance, Red Hat recommends booting with a Live CD or PXE boot and merging your snapshot when the system has booted successfully. Merging instructions are available in the Red Hat Enterprise Linux 7 LVM documentation, available from http://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/.
  • Rollback returns /var/log to the state it was in prior to upgrade. For auditing purposes, Red Hat recommends copying log files from installation to a separate location prior to initiating rollback.

2.6.3. Target Management with targetcli

Previous versions of Red Hat Enterprise Linux used tgtd for iSCSI target support and LIO, the Linux kernel target, only for Fibre-Channel over Ethernet (FCoE) targets through the fcoe-target-utils package.
Red Hat Enterprise Linux 7 now uses the LIO kernel target subsystem for FCoE, iSCSI, iSER (Mellanox InfiniBand) and SRP (Mellanox InfiniBand) storage fabrics. All fabrics can now be managed with the targetcli tool.

2.6.4. Persistent Device Names

Red Hat Enterprise Linux 7 makes the management of devices on the system easier by storing the mapping of device names (for example, sda, sdb, and others) and persistent device names (provided by udev in /dev/disk/by-*/) in kernel messages. This lets the system administrator identify the messages associated with a device, even if the device name changes from boot-to-boot.
The kernel /dev/kmsg log, which can be displayed with the dmesg command, now shows the messages for the symbolic links, which udev has created for kernel devices. These messages are displayed in the following format: udev-alias: device_name (symbolic_link symbolic link ...). For example:
udev-alias: sdb (disk/by-id/ata-QEMU_HARDDISK_QM00001)
Any log analyzer can display these messages, which are also saved in /var/log/messages through syslog.
To enable this feature add udev.alias=1 to the kernel command line in /etc/default/grub.

2.6.5. LVM cache volumes

LVM cache volume functionality is fully supported as of Red Hat Enterprise Linux 7.1. This feature allows users to create logical volumes with a small, fast device performing as a cache for larger, slower devices. See the lvmcache manual page for information on creating cache logical volumes.