Lustre 1.8

Lustre 1.8 introduces several robust, new features and improved system functionality. This page provides descriptions of these features and lists the benefits offered by upgrading to Lustre 1.8.

Adaptive Timeouts
The adaptive timeouts feature causes Lustre to use an adaptive mechanism to set RPC timeouts. RPC completion time histories are tracked on all servers, and estimates for future RPCs are reported back to clients. Clients use these estimates to set future RPC timeout values.

If server request processing slows down, the estimates increase and the clients allow more time for RPC completion. If RPCs queued up on the server approach their timeouts, the server sends early replies to the client, telling it to allow more time. Conversely, as a server speeds up, RPC timeout values decrease, allowing faster detection of non-responsive servers and faster attempts to reconnect to a server's failover partner.

Why should I upgrade to Lustre 1.8 to get it?
Adaptive timeouts offers these benefits:


 * Relieves users from having to tune the obd_timeout value.
 * Reduces RPC timeouts and disconnect/reconnect cycles.

Additional Resources
For more information about adaptive timeouts, see:


 * Architecture Page - Adaptive timeouts (use cases)
 * HLD - Adaptive RPC timeouts

Client Interoperability
The client interoperability feature enables Lustre 1.8 clients to work in Lustre 1.6 and 2.0 environments, despite differences in wire protocols and disk format (in the 2.0 release). This functionality provides client, server, network and storage interoperability during migration from 1.6-based, FID-less clusters (using ldiskfs for the filesystem) to clusters based on FIDs and the ZFS filesystem.

Client interoperability provides the following support:


 * Lustre 1.8 client can communicate with 1.8 components, including servers and other clients.
 * Lustre 1.8 client can communicate with 1.6 components, including servers and other clients.
 * Lustre 1.8 client can communicate with 2.0 servers.

Why should I upgrade to Lustre 1.8 to get it?
Client interoperability offers these benefits:


 * Enables Lustre clients to communicate with servers supporting FIDs.

Additional Resources
For more information on client interoperability, see:


 * << x-ref to 1-pager >>
 * Architecture page - Interoperability FIDs and ZFS
 * HLD - Interoperability at the Server Side
 * HLD - Sptlrpc interoperability
 * DLD - Interoperable Client Recovery
 * DLD - Sptlrpc interoperability
 * Feature tracking - BZ 11824

OSS Read Cache
The OSS read cache feature provides read-only caching of data on an OSS. It uses a regular Linux pagecache to store the data. OSS read cache improves Lustre performance when several clients access the same data set, and the data fits the OSS cache (which can occupy most of the available memory). The overhead of OSS read cache is insignificant on modern CPUs, and cache misses do not negatively impact performance compared to Lustre releases before OSS read cache was available.

Why should I upgrade to Lustre 1.8 to get it?
OSS read cache can improve Lustre performance, and offers these benefits:


 * Allows OSTs to cache read data more frequently
 * Improves repeated reads to network speeds vs. disk speeds
 * Provides the building block for OST write cache (small write aggregation)

Additional Resources
For more information on OSS read cache, see:


 * << x-ref to 1-pager >>
 * Feature tracking - BZ 12182
 * << x-ref to feature test plan >>

OST Pools
The OST pools feature enables you to specify and manage a group of OSTs for file striping purposes. For instance, a group of local OSTs could be defined for faster access; a group of higher-performance OSTs could be defined for premium users; a group of non-RAID OSTs could be defined for scratch files; or groups of OSTs could be defined for particular file types.

Pools are defined by the system administrator, using regular Lustre tools (lctl). Pool usage is specified and stored along with other striping information (e.g., stripe count, stripe size) for directories or individual files (lfs setstripe or llapi_create_file). Traditional automated OST selection optimizations (QOS) occur within a pool (e.g., free-space leveling within the pool). OSTs can be added or removed from a pool at any time (and existing files always remain in place and available.)

OST pools characteristics include:


 * An OST can be associated with multiple pools
 * No ordering of OSTs is implied or defined within a pool
 * OST membership in a pool can change over time

NOTE: In its current implementation, the OST pools feature does not implement an automated policy; it must be managed directly by administrator/user. It is a building block for policy-managed storage.

Why should I upgrade to Lustre 1.8 to get it?
OST pools offers these benefits:


 * Allows sets of OSTs to be managed via named groups
 * Pools can identify heterogeneous OSTs within the same filesystem
 * Fast vs. slow disks
 * Local network vs. remote network (e.g. WAN)
 * RAID 1 vs. RAID5, etc.
 * Specific OSTs for users/groups/applications
 * Easier disk usage policy implementation for administrators
 * Hardware can be more closely optimized for particular usage patterns
 * Human-readable stripe mappings

Additional Resources
For more information on OST pools, see:


 * << x-ref to 1-pager >>
 * Architecture page - OST pools
 * DLD - OST Pools
 * Feature tracking - BZ 16668
 * Feature tracking - BZ 15899
 * Feature tracking - BZ 14836

Version-Based Recovery
Version-based Recovery (VBR) improves the robustness of client recovery operations and allows Lustre to recover, even if multiple clients fail at the same time as the server. With VBR, recovery is more flexible; not all clients are evicted if some miss recovery, and a missed client may try to recover after the server recovery window.

Why should I upgrade to Lustre 1.8 to get it?
VBR functionality in Lustre 1.8 allows more flexible recovery after a failure. In previous Lustre releases, recovery would stop if a client was missing and the remaining clients would be evicted. With VBR, the recovery will continue even if some clients are missed, and the missed clients may try to recover later. With VBR, Lustre clients may successfully recover in various scenarios.

VBR offers these benefits:


 * Improves the robustness of client recovery operations
 * Allows Lustre recovery to work even if multiple clients fail at the same time as the server, if the remaining clients are working independently
 * Provides a building block for disconnected client operations

Additional Resources
For more information on VBR, see:


 * << x-ref to 1-pager >>
 * Architecture page - VBR
 * DLD - Version-based recovery
 * << BZ feature tracking >>