Chapter 2. What’s New

Contents

2.1. What’s New in SLES 11 SP1
2.2. What’s New in SLES 11

The features and behavior changes noted in this section were made for SUSE® Linux Enterprise Server 11.

2.1. What’s New in SLES 11 SP1

In addition to bug fixes, the features and behavior changes noted in this section were made for the SUSE® Linux Enterprise Server 11 SP1 release.

2.1.1. Saving iSCSI Target Information

In the YaSTNetwork ServicesiSCSI Target function, a Save option was added that allows you to export the iSCSI target information. This makes it easier to provide information to consumers of the resources.

2.1.2. Modifying Authentication Parameters in the iSCSI Initiator

In the YaSTNetwork ServicesiSCSI Initiator function, you can modify the authentication parameters for connecting to a target devices. Previously, you needed to delete the entry and re-create it it in order to change the authentication information.

2.1.3. Allowing Persistent Reservations for MPIO Devices

A SCSI initiator can issue SCSI reservations for a shared storage device, which locks out SCSI initiators on other servers from accessing the device. These reservations persist across SCSI resets that might happen as part of the SCSI exception handling process.

The following are possible scenarios where SCSI reservations would be useful:

  • In a simple SAN environment, persistent SCSI reservations help protect against administrator errors where a LUN is attempted to be added to one server but it is already in use by another server, which might result in data corruption. SAN zoning is typically used to prevent this type of error.

  • In a high-availability environment with failover set up, persistent SCSI reservations help protect against errant servers connecting to SCSI devices that are reserved by other servers.

2.1.4. MDADM 3.0.2

Use the latest version of the Multiple Devices Administration (MDADM, mdadm) utility to take advantage of bug fixes and improvements.

2.1.5. Boot Loader Support for MDRAID External Metadata

Support was added to use the external metadata capabilities of the MDADM utility version 3.0 to install and run the operating system from RAID volumes defined by the Intel* Matrix Storage Technology metadata format. This moves the functionality from the Device Mapper RAID (DMRAID) infrastructure to the Multiple Devices RAID (MDRAID) infrastructure, which offers the more mature RAID 5 implementation and offers a wider feature set of the MD kernel infrastructure. It allows a common RAID driver to be used across all metadata formats, including Intel, DDF (common RAID disk data format), and native MD metadata.

2.1.6. YaST Install and Boot Support for MDRAID External Metadata

The YaST® installer tool added support for MDRAID External Metadata for RAID 0, 1, 10, 5, and 6. The installer can detect RAID arrays and whether the platform RAID capabilities are enabled. If RAID is enabled in the platform BIOS for Intel Matrix Storage Manager, it offers options for DMRAID, MDRAID (recommended), or none. The initrd was also modified to support assembling BIOS-based RAID arrays.

2.1.7. Improved Shutdown for MDRAID Arrays that Contain the Root File System

Shutdown scripts were modified to wait until all of the MDRAID arrays are marked clean. The operating system shutdown process now waits for a dirty-bit to be cleared until all MDRAID volumes have finished write operations.

Changes were made to the startup script, shutdown script, and the initrd to consider whether the root (/) file system (the system volume that contains the operating system and application files) resides on a software RAID array. The metadata handler for the array is started early in the shutdown process to monitor the final root file system environment during the shutdown. The handler is excluded from the general killall events. The process also allows for writes to be quiesced and for the array’s metadata dirty-bit (which indicates whether an array needs to be resynchronized) to be cleared at the end of the shutdown.

2.1.8. MD over iSCSI Devices

The YaST installer now allows MD to be configured over iSCSI devices.

If RAID arrays are needed on boot, the iSCSI initiator software is loaded before boot.md so that the iSCSI targets are available to be auto-configured for the RAID.

For a new install, Libstorage creates an /etc/mdadm.conf file and adds the line AUTO -all. During an update, the line is not added. If /etc/mdadm.conf contains the line

AUTO -all

then no RAID arrays are auto-assembled unless they are explicitly listed in /etc/mdadm.conf.

2.1.9. MD-SGPIO

The MD-SGPIO utility is a standalone application that monitors RAID arrays via sysfs(2). Events trigger an LED change request that controls blinking for LED lights that are associated with each slot in an enclosure or a drive bay of a storage subsystem. It supports two types of LED systems:

  • 2-LED systems (Activity LED, Status LED)

  • 3-LED systems (Activity LED, Locate LED, Fail LED)

2.1.10. Resizing LVM 2 Mirrors

The lvresize, lvextend, and lvreduce commands that are used to resize logical volumes were modified to allow the resizing of LVM 2 mirrors. Previously, these commands reported errors if the logical volume was a mirror.

2.1.11. Updating Storage Drivers for Adapters on IBM Servers

Update the following storage drivers to use the latest available versions to support storage adapters on IBM servers:

  • Adaptec™: aacraid, aic94xx

  • Emulex™: lpfc

  • LSI™: mptas, megaraid_sas

    The mptsas driver now supports native EEH (Enhanced Error Handler) recovery, which is a key feature for all of the IO devices for Power platform customers.

  • qLogic™: qla2xxx, qla3xxx, qla4xxx

2.2. What’s New in SLES 11

The features and behavior changes noted in this section were made for the SUSE® Linux Enterprise Server 11 release.

2.2.1. EVMS2 Is Deprecated

The Enterprise Volume Management Systems (EVMS2) storage management solution is deprecated. All EVMS management modules have been removed from the SUSE Linux Enterprise Server 11 packages. Your EVMS-managed devices should be automatically recognized and managed by Linux Volume Manager 2 (LVM2) when you upgrade your system. For more information, see Evolution of Storage and Volume Management in SUSE Linux Enterprise.

For information about managing storage with EVMS2 on SUSE Linux Enterprise Server 10, see the SUSE Linux Enterprise Server 10 SP3: Storage Administration Guide.

2.2.2. Ext3 as the Default File System

The Ext3 file system has replaced ReiserFS as the default file system recommended by the YaST tools at installation time and when you create file systems. ReiserFS is still supported. For more information, see File System Future Directions on the SUSE Linux Enterprise 10 File System Support Web page.

2.2.3. JFS File System Is Deprecated

The JFS file system is no longer supported. The JFS utilities were removed from the distribution.

2.2.4. OCFS2 File System Is in the High Availability Release

The OCFS2 file system is fully supported as part of the SUSE Linux Enterprise High Availability Extension.

2.2.5. /dev/disk/by-name Is Deprecated

The /dev/disk/by-name path is deprecated in SUSE Linux Enterprise Server 11 packages.

2.2.6. Device Name Persistence in the /dev/disk/by-id Directory

In SUSE Linux Enterprise Server 11, the default multipath setup relies on udev to overwrite the existing symbolic links in the /dev/disk/by-id directory when multipathing is started. Before you start multipathing, the link points to the SCSI device by using its scsi-xxx name. When multipathing is running, the symbolic link points to the device by using its dm-uuid-xxx name. This ensures that the symbolic links in the /dev/disk/by-id path persistently point to the same device regardless of whether multipathing is started or not. The configuration files (such as lvm.conf and md.conf) do not need to be modified because they automatically point to the correct device.

See the following sections for more information about how this behavior change affects other features:

2.2.7. Filters for Multipathed Devices

The deprecation of the /dev/disk/by-name directory (as described in Section 2.2.5, “/dev/disk/by-name Is Deprecated”) affects how you set up filters for multipathed devices in the configuration files. If you used the /dev/disk/by-name device name path for the multipath device filters in the /etc/lvm/lvm.conf file, you need to modify the file to use the /dev/disk/by-id path. Consider the following when setting up filters that use the by-id path:

  • The /dev/disk/by-id/scsi-* device names are persistent and created for exactly this purpose.

  • Do not use the /dev/disk/by-id/dm-* name in the filters. These are symbolic links to the Device-Mapper devices, and result in reporting duplicate PVs in response to a pvscan command. The names appear to change from LVM-pvuuid to dm-uuid and back to LVM-pvuuid.

For information about setting up filters, see Section 7.2.3, “Using LVM2 on Multipath Devices”.

2.2.8. User-Friendly Names for Multipathed Devices

A change in how multipathed device names are handled in the /dev/disk/by-id directory (as described in Section 2.2.6, “Device Name Persistence in the /dev/disk/by-id Directory”) affects your setup for user-friendly names because the two names for the device differ. You must modify the configuration files to scan only the device mapper names after multipathing is configured.

For example, you need to modify the lvm.conf file to scan using the multipathed device names by specifying the /dev/disk/by-id/dm-uuid-.*-mpath-.* path instead of /dev/disk/by-id.

2.2.9. Advanced I/O Load-Balancing Options for Multipath

The following advanced I/O load-balancing options are available for Device Mapper Multipath, in addition to round-robin:

  • Least-pending

  • Length-load-balancing

  • Service-time

For information, see Section 7.6.2.1, “Understanding Priority Groups and Attributes”.

2.2.10. Location Change for Multipath Tool Callouts

The mpath_* prio_callouts for the Device Mapper Multipath tool have been moved to shared libraries in/lib/libmultipath/lib*. By using shared libraries, the callouts are loaded into memory on daemon startup. This helps avoid a system deadlock on an all-paths-down scenario where the programs need to be loaded from the disk, which might not be available at this point.

2.2.11. Change from mpath to multipath for the mkinitrd -f Option

The option for adding Device Mapper Multipath services to the initrd has changed from -f mpath to -f multipath.

To make a new initrd, the command is now:

mkinitrd -f multipath