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 This work represents the majority of the client side support needed for HSM. The remaining server side support and support for HSM to be functional will be completed in 2.5. | 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 | |
| Quota Enforcement | Rewrite of server side quota to deal with OSD restructuring to work with both ldiskfs and ZFS. This work also addresses some enhancements to the original implementation. | LU-1842 | |
| MGS over OSD | Change the Lustre MGS to replace non-portable storage APIs with the OSD API, including use of the new LLOG API for storing Lustre file system configuration information. | LU-1301 | |
| Changelog | LU-2034 | ||
| ZFS OSD Utilities | Lustre utilities require an update in order to properly function with a ZFS-based OSD. | LU-1581 | |
| FID on OST Infrastructure | With this feature, the object on OST will be identified by a FID, instead of object id. And the disk Layout of OST will be changed, 1) The existing data objects on OST will still be stored into O/0/ 2) But the new created objects on OST will be stored under O/<seq_number>/ | LU-1445 | |
| DNE Phase I: Remote Directories | This phase introduces a useful minimum of distributed metadata functionality. The purpose primarily to ensure that efforts concentrate on clean code restructuring for DNE. The phase focuses on extensive testing to shake out bugs and oversights not only in the implementation but also in administrative procedures. DNE brings new usage patterns that must necessarily adapt to manage multiple metadata servers. | LU-1187 | |
| Quota Support with DNE | While the new quota architecture was developed with DNE in mind, some more work will still be required to support DNE once it is ready to land onto master (DNE was developed in a separate branch). This includes:
| LU-2183 | |
| LNET Networks Hashing | This feature changed the table in LNet which keeps track of all remote networks into a hash table. This speeds up access to these entries when dealing with a very large number of remote networks (over 1000). In addition, a new module parameter, rnet_htable_size, was added to allow customers to control the size of this hash table. | LU-2466 | |
| Ability to Disable Pinging | In Lustre 2.4, a new ptlrpc module parameter, "suppress_pings", is introduced to provide an option for reducing excessive OBD_PING messages in large clusters. The parameter is a switch and affects all MDTs and OSTs on a node. (MGS pings can not be suppressed.) By default, it is off (zero), giving a behavior identical to previous implementations. If it is on (non-zero), all clients of the affected targets who understand OBD_CONNECT_PINGLESS will know, at connect time, that pings are not required and will suppress keep-alive pings. | LU-2467 |
Overview
Content Tools