WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Lustre 1.8: Difference between revisions

From Obsolete Lustre Wiki
Jump to navigationJump to search
Line 15: Line 15:
* Improves repeated reads to network speeds vs. disk speeds
* Improves repeated reads to network speeds vs. disk speeds
* Provides the building block for OST write cache (small write aggregation)
* 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>>


==OST Pools==
==OST Pools==

Revision as of 10:45, 8 November 2008

<< placeholder for Lustre 1.8 page >>

Lustre 1.8 introduces several robust new features.


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. In some cases, OSS read cache can improve Lustre performance. The most likely case is when clients share same set of data and the data fits the OSS cache (which can occupy most of the available memory). Our profiling shows that 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>>

OST Pools

The OST pools feature allows you to specify an arbitrary 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.)

These are several characteristics of OST pools:

  • 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

Why should I upgrade to Lustre 1.8 to get it?

OST pools offers these benefits:

  • Easier disk usage policy implementation for administrators
  • Hardware can be more closely optimized for particular usage patterns
  • Human-readable stripe mappings

Version Based Recovery

What is it?

Version-Based Recovery is a mechanism that allows Lustre clients to recover in less strict order and permits a client to replay request long after the main recovery is completed. Independent changes should be recovered even if some clients are missing.

Why should I upgrade to Lustre 1.8 to get it?

Version-based recovery allows more flexible re-integration after a failure as compared to Lustre 1.6. Previously, the recovery stops if some client is missing and all other clients were evicted. Recovery in Lustre 1.8 isn't stopping if some clients are missed and other clients will use version checking to recover. Missed clients may try to recover later. Therefore more clients may recover correctly in various recovery scenarios

  • Improves 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
  • Building block for disconnected client operations