Storage changes in RHEL7 - Everybody should Know

 

This Post contains only Storage changes available in RHEL 7. I have tried to provide those changes in details.

If you are interested in learning, Request you to go through the below recommended tutorial.

DevOps Full Course Tutorial for Beginners - DevOps Free Training Online
Docker Full Course Tutorial for Beginners - Docker Free Training Online
Kubernetes Full Course Tutorial for Beginners - Kubernetes Free Training Online
Ansible Full Course Tutorial for Beginners - Ansible Free Training Online
Openstack Full Course Tutorial for Beginners - Openstack Free Training Online
Learn Linux, DevOps and Cloud

Storage changes in RHEL7

XFS

The new default file system for RHEL 7 is XFS. Its main advantage is to allow the creation of file system up to 500TB (50TB in RHEL6) compare to the 50TB limit of ext4 (16TB in RHEL6). This is in line with the requirements of some big Red Hat customers.
According to Ric Wheeler (the lead for Red Hat‘s storage and filesystem), XFS would present these additional attractive features:

1.     best performance for most workloads (especially with high speed storage and larger number of cores),


2.     tends to be less CPU intensive (better optimizations around lock contention, etc),


3.     the most robust at large scale – has been run at hundred plus TB sizes for many years (and today’s storage is getting way bigger, 16TB is about half a shelf of drives),


4.     the most common file system in multiple key upstream communities: most common base for ceph, gluster and openstack more broadly,


5.     pioneered most of the techniques now in ext4 for performance (like delayed allocation).

Also, unlike most of the other file systems, XFS doesn’t execute any file system check at boot time. In case of trouble, you have to rely on the xfs_repair command.

However, XFS has got one serious drawback. It doesn’t allow file systems to be reduced even when unmounted (shrinking support is considered but not available). This is a good reason to stay with ext4 when big file systems are not needed. In addition, ext4 tends to be faster with some specific workloads like single threaded, metadata intensive workloads.

BTRFS

BTRFS is a technology preview. Although BTRFS (B–TRee File System) is not completely production-ready, its capabilities (copy-on-write, snapshot, filesystem online shrink, etc) are amazing.

However, about BTRFS and SELinux, here is what Dan Walsh from Red Hat wrote in one of his articles (Bringing new security features to Docker): “SELinux currently will only work with the device mapper back end. SELinux does not work with BTRFS. BTRFS does not support context mount labeling yet, which prevents SELinux from relabeling all content when the container starts via the mount command. Kernel engineers are working on a fix for this and potentially Overlayfs if it gets merged into the container.”

NFS

The NFS 4.1 version is now supported, bringing better performance on increasingly-congested networks.
Better Parallel NFS client support has been added to improve integration with commercially available pNFS servers.

GRUB2

As GRUB Legacy was not evolving anymore, it was necessary to move to another solution. GRUB2 comes as a complete rewriting and provides the following new features:

1.     ability to boot on various file systems (xfs, ext4, ntfs, hfs+, raid, etc),


2.     gzip files decompression on the fly,


3.     management of all disk geometries,


4.     support for GPT (GUID Partition Tables) and MBR (Master Boot Record),


5.     portability with different architectures (BIOS, EFI, Coreboot, etc),


6.     ability to load modules at execution time.

GFS2

GFS2 journaling code has been improved to reduce the number of journal update operations, consolidate IO operations and increase overall GFS2 file system performance.
In addition, GFS2 file system creation tools now utilize device topology knowledge, deal with RAID stripe alignment, and carefully orchestrate the placement of performance critical file system elements, such as journals and resource groups. This improvement increases the scalability and performance of GFS2 not only during file system creation time but also during file system usage.

iSCSI

The SCSI Target Daemon, tgtd, has been replaced by the LIO kernel target subsystem, standard open source SCSI target for block storage. The latter is now used for all of the following storage fabrics: FCoE, iSCSI, iSER, and SRP.

FS-Cache

FS-Cache is a fully supported feature in the Red Hat Enterprise Linux 7. It provides a persistent local cache that can be used by file systems to take data retrieved over the network and cache it on a local disk. This helps minimize network traffic for users accessing data from a file system mounted over the network (for example, NFS). FS-Cache can significantly reduce the network and server loading by satisfying read requests locally without consuming network bandwidth.

IO Scheduler

The IO scheduler policy has changed with Red Hat Enterprise Linux 7.
The default IO Scheduler is now CFQ for SATA drives and Deadline for everything else.

Indeed, for faster storage than SATA drives, Deadline outperforms CFQ, giving a performance increase without any special tuning.

Related Content on Linux might be useful to you to improve your Linux Skills.

How to Configure IP Address on Ubuntu using Netplan
How to Access Linux Server from Windows Remotely
Configure SSH Passwordless Login Authentication (SSH-keygen)
How to Create LVM Partition in Linux – LVM Tutorial
Install & Configure Samba Server on Linux (RHEL7 / CentOS7)

How to Create LVM Snapshot Volume in Linux

How to Create and Delete Partitions using fdisk in Linux

Keep practicing and have fun. Leave your comments if any.

Support Us: Share with your friends and groups.

Stay connected with us on social networking sites, Thank you.

YouTube | Facebook | Twitter | Pinterest | Telegram