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.

Difference between revisions of "Lustre 1.8"

From Obsolete Lustre Wiki
Jump to navigationJump to search
 
Line 3: Line 3:
 
Lustre 1.8 introduces several robust new features.  
 
Lustre 1.8 introduces several robust new features.  
  
VBR
+
 
OST pools
+
==OSS Read Cache==
ATs
+
===What is it?===
Read-only cache
+
OSS read cache provides read-only caching on OSS for data. It uses a regular Linux pagecache to store data. In some cases, OSS read cache can improve performance. The most likely case is when clients share same set of data and the
 +
data fits the OSS's cache (which can occupy most of 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 for this feature?===
 +
Improve performance in a few use cases as described above.
 +
 
 +
* Allows OST to cache frequently read data
 +
* Can improve repeated reads to network speeds vs. disk speeds
 +
* Building block for OST write cache (small write aggregation)
 +
 
 +
 
 +
==OST Pools==
 +
* Allows managing sets of OSTs 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. RAID 5, etc.
 +
* Specific OSTs for users/groups/applications
 +
* Current implementation does NOT implement any automated policy, must be managed directly by administrator/user
 +
* Building block for policy managed storage
 +
 
 +
 
 +
==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 for this feature?===
 +
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

Revision as of 22:40, 7 November 2008

<< placeholder for Lustre 1.8 page >>

Lustre 1.8 introduces several robust new features.


OSS Read Cache

What is it?

OSS read cache provides read-only caching on OSS for data. It uses a regular Linux pagecache to store data. In some cases, OSS read cache can improve performance. The most likely case is when clients share same set of data and the data fits the OSS's cache (which can occupy most of 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 for this feature?

Improve performance in a few use cases as described above.

  • Allows OST to cache frequently read data
  • Can improve repeated reads to network speeds vs. disk speeds
  • Building block for OST write cache (small write aggregation)


OST Pools

  • Allows managing sets of OSTs 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. RAID 5, etc.
  • Specific OSTs for users/groups/applications
  • Current implementation does NOT implement any automated policy, must be managed directly by administrator/user
  • Building block for policy managed storage


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 for this feature?

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