NLM
Observations
- External datastreams. Most of our binaries are of type E external. The migration tool migrates the Fedora objects, but not the type E external binaries (as expected). Thus we are left with object structure, metadata and RDF in OCFL format, but not the actual binaries themselves. If, how, when and where to migrate external binaries to an OCFL structure is TBD, but a major consideration for us in adopting OCFL.
- Speed. The tool migrates objects at the rate of 15K-40K objects per hour. This should be manageable for our purpose.
- For the "citations" repository, it consistently takes 30 minutes to build the datastream index before starting the migration. This server has 3.8M managed datastreams (1 per object). The option to cache this index when resuming migrations is helpful.
- CPU time. Consumes about 30%.
- Layout. In flat and pairtree migrations the PID is used to form the path; for example PID nlm:nlmuid-101588995-bk (stored FOXML file name nlm_nlmuid-101588995-bk) becomes /ocfl/nl/m+/nl/mu/id/-1/01/58/89/95/-b/k/5-bk. Characters such as – are problematic in Linux. See .
- It would be nice to declare use of another field, or input map, to dictate the value to use for layout path generation. For example, it may be nice to use 101588995_bk to generate a path for PID nlm:nlmuid-101588995-bk. Also included in .
- Migrated datastreams have no file extension. It would be nice if migrated datastreams have a file extension inferred from the MIME type; e.g. DC.xml instead of just DC, and OCR.txt instead of just OCR. This should particularly help out with in-line XML datastreams.
- OCFL versions appear to be created based on datastream timestamps. Each unique timestamp creates a new OCFL version, even if they were part of the same Fedora version in the AUDIT trail and differed only by milliseconds.
Issues
- Occasional "Unable to delete staging" messages, which stops a migration. See and .
- Migrated objects from the "collections" repository generate approx. 40 files in OCFL from a single Fedora 3 FOXML file. This repo with 4M objects could generate 160M files. We have already run out of filesystem inodes when attempting migration runs. It may be useful to optimize the number of generated files to mitigate this issue.
Migration Tests
This section logs migration tests for our two different repository environments, "collections" and "citations".
Repository environment #1: "collections".
Approx. 4.3M records in legacy format, mostly books, pages and still images. Objects have many datastreams, binaries are generally type E external.
Fedora 3.8.1. VM with 4 cores, 8 GB RAM. CentOS release 6.10 (Final), Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
Number of objects | Execution Time | Source Layout | Dest. Layout | Migration tool version | Notes |
|---|---|---|---|---|---|
| 1000 | 4 min | legacy | pairtree | 11/26/19 | 1K fedora items produced 42K+ files |
| 1000 | 3 min | legacy | truncated | 11/26/19 | 1K fedora items produced 43K+ files |
| 100,000 | 6.5 hours | legacy | flat | 11/26/19 | |
| 1 million | ~3 days | legacy | pairtree | 11/26/19 | Execution crashed twice for "unable to delete staging" file issues, resume option had no issues running |
Repository environment #2: "citations".
Approx. 3.8M records in akubra format, all citations with one small type M XML datastream (the citation payload).
Fedora 3.8.1. VM with 1 core, 8 GB RAM. CentOS release 6.10 (Final), Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
Number of objects | Execution Time | Source Layout | Dest. Layout | Migration tool version | Notes |
|---|---|---|---|---|---|
| 2000 | 32 min | akubra | pairtree | 11/26/19 | Includes 30 min to build the index. Hung on completion-could not delete index. |
| 10,000 | 42 min | akubra | flat | 11/26/19 | Includes 30 min to build the index. Hung on completion-could not delete index. |
| 554,695 | 13 hours | akubra | flat | 11/26/19 | Attempted to migrate 1M records. Includes 30 min to build the index. Crashed due to UnrecognizedPropertyException. |
