Removal of librtkaio from glibc
Summary
Remove librtkaio support from glibc in Fedora 24.
Owner
- Name: Carlos O'Donell
- Email: carlos@redhat.com
- Release notes owner:
Current status
Detailed Description
On July 2003 the rtkaio add-on was added to Fedora in glibc 2.3.2-64. The rtkaio add-on provided a POSIX realtime API interface that used linux kernel Asynchronous IO support (KAIO) to provide high performance AIO for a small subset of files (those using O_DIRECT, and not all file types). Typically the use case was databases or high-speed transactional systems that needed fast AIO. The libraries were installed under /lib64/rtkaio/ e.g. /lib64/rtkaio/librt.so.1 (symlink to /lib64/rtkaio/librtkaio-X.Y.so with SONAME librt.so.1) and could be used by preloading (LD_PRELOAD), dynamic linker lookup path changes (LD_LIBRARY_PATH) or by directly opening the shared library (dlopen). This accelerated access to file was used by customers like Sybase during the development of their database Sybase ASE (now owned by SAP).
It has been 12 years since rtkaio was released, and while it has seen some uptake, the only known usage example is Sybase ASE. Sybase now exclusively uses the Linux Kernel Asynchronous I/O Library (libaio) for over 10 years ago and no longer use rtkaio. The libaio project provides a unique API that is tailored to doing very fast AIO. An analysis of Fedora shows no packages using rtkaio. Lastly the rtkaio add-on was never contributed upstream, likely because it never provided full POSIX conformance and worked only with a small subset of the required POSIX realtime features, those supported by KAIO.
It is the conclusion of the Fedora glibc team that the maintenance burden of rtkaio is no longer warranted. The glibc team suggest rtkaio be deprecated and removed. Application developers should use libaio if they want high performance KAIO, or use librt if they want portable and flexible AIO.
What are the consequences of removing rtkaio?
- Application developers using rtkaio will see a performance decrease if they were previously using KAIO on O_DIRECT opened files, but should otherwise see no semantic changes in their applications.
- Application developers using LD_PRELOAD will see a warning that the preloaded library is missing, but the application will load the normal librt and continue to operate correctly.
- Application developers using LD_LIBRARY_PATH will see no warning, and the application will load the normal librt and continue to operate correctly.
- Application developers using dlopen will see a failure from dlopen since the library is missing. This is mitigated by shipping a symlink from the rtkaio library to librt in the official Fedora release.
The rtkaio library and the librt library are ABI and API compatible, and therefore interchangeable. As long as we provide one of them we will meet our application compatibility requirements. We will continue to provide the POSIX realtime library (librt) forever.
The following plan of action is suggested:
- Immediately remove rtkaio from Fedora Rawhide, deprecating the library.
See https://bugzilla.redhat.com/show_bug.cgi?id=1227855
No compatibility symlinks are provided for Rawhide. We want to use Rawhide to detect if any applications are actually using rtkaio. Before the F24 branch a compatibility symlink will be added and left in place for a full release after which it will be removed.
Benefit to Fedora
Removal of this unused feature will allow the Fedora glibc team focus on other bugs and features with higher priority.
Scope
- Proposal owners: Update glibc and remove librtkaio.
- Other developers: Aside from Carlos O'Donell <carlos@redhat.com>, Siddhesh Poyarekar <siddhesh@redhat.com>, Torvald Riegel <triegel@redhat.com>, Martin Sebor <msebor@redhat.com>, and Patsy Franklin <pfrankli@redhat.com>, no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 24 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when librtkaio is removed.
- Release engineering: In general coordination with release engineering is not required. A mass rebuild is not required.
- Policies and guidelines: The policies and guidelines do not need to be updated.
Upgrade/compatibility impact
There are some upgrade issues with the removal librtkaio, but they will be handled by the compatibility symlink that will be provided which points to the standard librt.
How To Test
The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 1000+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones.
User Experience
Uses of librtkaio may see decreased performance, and will need to switch to libaio to regain that performance.
Dependencies
All packages do not need to be rebuilt.
Contingency Plan
- Contingency mechanism: Given that Rawhide has started tracking GLIBC 2.23, no show-stopper problems are expected. In the unlikely event a major problem were discovered, we could leave librtkaio in glibc for another release.
- Contingency deadline: Beta freeze.
- Blocks release? No. We will put librtkaio back into glibc if there are problems.
Documentation
The glibc manual contains the documentation for the release and doesn't need any more additional work.
Release Notes
The release notes for the librtkaio removal are as follows:
The GNU C Library version 2.23 in Fedora will no longer provide a POSIX Realtime library that is based solely around the Linux Kernel Asynchronous IO interfaces (librtkaio). Instead the binary compatible POSIX Realtime library (librt) will be used for all applications. Applications expecting librtkaio may experience a performance degradation and it is suggested they upgrade to libaio. A compatibility symlink is being provided for this release to ensure a smooth transition, but that symlink may be removed in future releases.