File Systems and Storage

`cryptsetup` Released at Version 2.7

cryptsetup version 2.7 includes the following changes:

libcryptsetup improved support for LUKS encrypted devices in the kdump enabled systems.
Critical fixes for LUKS2 SED OPAL feature.
known or already fixed issues with LUSK2 SED OPAL feature avoided.

Snapshot Manager

The Snapshot Manager, snapm, is a new software component designed to help manage system state snapshots when a system is using copy-on-write and thinly provisioned logical volume management (LVM2) volumes. You can use snapm to create snapshots of the system at a moment in time and to rollback to that system state based on the snapshot that you have taken.

See https://github.com/snapshotmanager/snapm for more information about this utility.

`device-mapper-multipath` Released at Version 0.9.9

The device-mapper-multipath package is released at version 0.9.9, providing various bug fixes and enhancements.

This update includes several notable changes and enhancements, including:

The multipathd.socket systemd unit is no longer enabled by default. However, multipathd continues to run automatically on boot. If stopped, you must restart it manually or update the multipathd.socket systemd file to uncomment the line:
```
# WantedBy=sockets.target
```
multipathd runs as a real-time process with a moderate priority (10) by default. If unsuccessful, it continues to run as a normal process, but with an increased priority.
The systemctl reload multipathd.service or multipathd reconfigure commands reload a device only if something has changed, instead of reloading every multipath device.
A new path_grouping_policy called group_by_tpg is introduced to group paths by their alua target port group.
Configuration settings detect_pgpolicy and detect_pgpolicy_use_tpg are introduced to control the path grouping policy.
- detect_pgpolicy is a configuration setting that controls whether multipath automatically detects the path grouping policy for a device. If enabled, multipath sets the path_grouping_policy to group_by_prio or group_by_tpg based on the prioritizer used.
- detect_pgpolicy_use_tpg is a configuration setting that controls whether detect_pgpolicy sets the path_grouping_policy to group_by_tpg when the prioritizer is alua or sysfs. If enabled, detect_pgpolicy sets the policy to group_by_tpg; otherwise, it sets the policy to group_by_prio.

`dm-vdo` Module for RHCK

The dm-vdo module is added to RHCK, replacing the kmod-kvdo module.

NVMe SED Available

The nvme-cli and cryptsetup commands can automate encryption management and drive unlocking for NVMe Self-Encrypting Drives (SED). NVMe SED is an Opal storage specification of hardware encryption technology that provides a secure way to protect data at rest by encrypting data stored on the drive.

To use NVMe SED options on an NVMe disk with nvme-cli, you can perform the following actions:

Discover SED features on a SED Opal device. See the nvme-sed-discover(1) manual page.
```
nvme sed discover /dev/nvme0n1
```
Initialize a SED Opal device for locking. See the nvme-sed-initialize(1) manual page.
```
nvme sed initialize /dev/nvme0n1
```
Lock a SED Opal device. See the nvme-sed-lock(1) manual page.
```
nvme sed lock /dev/nvme0n1
```
Unlock a SED Opal device. See the nvme-sed-unlock(1) manual page.
```
nvme sed unlock /dev/nvme0n1
```
Change the locking password on a SED Opal device. See the nvme-sed-password(1) manual page.
```
nvme sed password /dev/nvme0n1
```
Revert a SED Opal device from it's locking state. See the nvme-sed-revert(1) manual page.
```
nvme sed revert /dev/nvme0n1
```

These commands provide a flexible and secure way to manage NVMe SEDs, to automate encryption management and drive unlocking.

NFS with TLS Support

NFS with Transport Layer Security (TLS) is now fully supported on RHCK, enhancing NFS security by encrypting RPC traffic.

NFS with TLS is available in previous releases with UEK R7U3 and later. NFS with TLS continues to be support with UEK 8.

Atomic Write

Oracle Linux 10 introduces atomic write in RHCK, ensuring that write operations are atomic and preventing partial data writes or torn writes.

Atomic write is useful for applications that require high data consistency and reliability, such as databases. By ensuring that write operations are atomic, applications can optimize their performance and reduce the risk of data corruption or loss.

When atomic write is enabled, the file system, block layer, and drivers work together to ensure that write operations are run as a single, atomic unit.

To take advantage of atomic write, applications must use the RWF_ATOMIC flag when performing write operations by using various programming interfaces, such as the write() system call or higher-level libraries and frameworks.