AVAILABLE: Fedora 3.7.1–Resolves Rare, but Severe Fedora 3.x Storage Issue

Wed, 2013-10-30 12:31 -- carol

From the Fedora Repository Team

Winchester, MA  Fedora Commons Repository 3.7.1, a bugfix release, is now available. It is highly recommended that all users of the 3.x series upgrade to this release, especially if your repository matches the criteria listed in "Is my installation affected", below. Fedora Commons Repository 3.7.1 is available for download from Sourceforge, from Maven Central, or can be built from source from GitHub. Upgrade notes and instructions can be found on the DuraSpace wiki:

https://wiki.duraspace.org/display/FEDORA37/Fedora+Repository+3.7.x+Release+Notes

What motivated a release so soon after 3.7.0?
A long-standing error scenario was identified whereby under certain circumstances, if the backing database for a Fedora Commons installation became corrupted or was incompletely rebuilt, PIDs could be reused. Under the legacy store, this meant datastreams could be ‘orphaned’ and become inaccessible. In more limited circumstances under Akubra, there is a possibility that objects could be overwritten.

How does 3.7.1 address this issue?
The changes in 3.7.1 foreclose on this possibility under Akubra, and introduce another check against orphaned data under legacy stores. This is accomplished by additional querying of the LowLevelStorage module on object ingest.  Additionally, going forward from 3.7.1 the SQL rebuild utility will track normal completion of the indexing process, and Fedora will not start if the most recent rebuild did not finish normally.

Is my installation affected?
The following three conditions must be true for your installation to be a candidate for this issue:

1. Your Fedora 3.x installation uses sequential (non-random, non-UUID, non-NOID) PIDs generated by Fedora
2. Your upgrade/rebuild process operates in-place on the backing database
3. Previous rebuilds have failed or external processes can write to the backing DB.

As indicated above, the nature of the risk and its consequences vary by the type (implementation) of LowLevelStorage your repository is configured to use. Akubra-backed installations will not necessarily start with an incomplete or corrupted backing DB, so their chance of corruption is lessened. More technical discussion can be found in the issue tracker for FCREPO-1202.

How can I tell if my installation has encountered this problem?
The Fedora committers are working on a detection task to be built into the FCSU (Fedora Commons Storage Utility), but felt the fixed repository code should be released as soon as possible. An updated FCSU will be announced when it is available.

How does this impact the changes previously slated for 3.7.1?
The performance and library stability changes previously scheduled for 3.7.1 will be released as 3.7.2. A release candidate for 3.7.2, the last planned release in the 3.x line, should be publicly announced in early November.

RSS Feeds: 
preserve