Lustre 2.4.0 will be released in the Spring of 2013. This is its planned test matrix.
Server Support | Client Support |
---|---|
RHEL 6.4, | RHEL 6.4, FC/18 |
As well as ongoing stability improvements, there are a number of new features in the Lustre 2.4.0 release.
Feature | Summary | JIRA | Notes |
---|---|---|---|
Network Request Scheduler (NRS) | The Network Request Scheduler manages incoming RPC requests on a server to provide improved and consistent performance. It does this primarily by ordering request execution to avoid client starvation and to present a workload to the backend filesystem that can be optimized more easily. It may also change RPC concurrency as active fan-out varies to reduce latency seen by the client and limit request buffering on the server. | ||
4MB RPC | Currently Lustre maximum buffer size for a RPC sending I/O is 1MB. This work looks to change the amount of data transfer to allow the data sent to be a size to achieve peak performance with large I/O transfers to the back end disk. Also an additional benefit is the reduction in the round trip time to send the data. | ||
Update Wireshark Support for LNET and Lustre | This feature request is to do the following upgrades to Wireshark support: 1- Get both plugins building under the latest 1.4.x version of Wireshark (will be backwards compatible with 1.2.x). 2- Move them to a wireshark subdirectory of lustre/contrib to isolate them better 3- Create a Makefile to build and install the plugins (one does not exist today). | LU-1434 | |
Client Performance Improvements | Improve single client's performance | LU-744 | |
LFSCK Phase 1.5 | In LFSCK Phase 1.5 we will implement the functionality of verifying and rebuilding FID-in-dirent and linkEA under for the single-MDT case | LU-1866 | |
HSM Client Side Support Features | Dirty Flag, NDT LVB Support, Layout Lock, Temporary File Support, Flags, Layout Swapping, Activity Monitoring | LU-941, LU-1710, LU-1876, LU-2441, LU-1338, LU-2016, LU-2060 | |
Server Stack | The purpose of this feature is to change the order the server stack builds: now OSD (exporting specific disk filesystem) is instantiated first by obd_mount.c, then other services/device start. also struct lu_site (collection of in-core objects) is relocated to OSD so that it can be shared by different services like MDS and MGS. | LU-1711 | |
OSD-LLOG | Change the LLOG subsystem (which is used to store transaction logs for recovery and file system configuration data and changelogs) by replacing the use of non-portable storage APIs with the OSD API. Change the LLOG API to reflect the new transaction model created in the OSD API project | LU-1302 | |
LOD/OSP | Lustre 2.0 uses old Release 1.8 client-side stack components to connect to the OSTs for stripe object pre-creation and orphan management. This work will remove these components, replacing them with a new subsystem that implements transactional access to non-local OSDs to ensure a rigorous separation of client/server and server/server protocols which avoids existing recovery race conditions. | LU-1303 | |
OSD/MDT | Remove the last uses of non-portable storage APIs in the Lustre Release 2.0 metadata stack and update existing use of the OSD API to the new transaction model. | LU-1304 | |