NLM

Observations

1. 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.
2. Speed. The tool migrates objects at the rate of 15K-40K objects per hour. This should be manageable for our purpose.
3. 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.
4. CPU time. Consumes about 30%.
5. 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  Unable to locate Jira server for this macro. It may be due to Application Link configuration. .
6. 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  Unable to locate Jira server for this macro. It may be due to Application Link configuration. .
7. 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.   Unable to locate Jira server for this macro. It may be due to Application Link configuration.
8. 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.
9. Add XML declarations for migrated in-line datastreams.   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Issues

1. Occasional "Unable to delete staging" messages, which stops a migration.  See  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  and  Unable to locate Jira server for this macro. It may be due to Application Link configuration. .
2. 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.
3. Migrated external datastreams are not resolvable.  Unable to locate Jira server for this macro. It may be due to Application Link configuration.

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

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

Brown Univ

University of Wisconsin - Madison

Observations

1. Storage environment:  for the purposes of this test (and for our real migration), we are migrating from one CIFS-mounted remote filesystem to another CIFS-mounted remote filesystem.
2. Speed: The tool migrates approximately x objects/hr.  At this rate, it will take approximately x days to migrate the entire repository,
3. Datastream index:  takes about x minutes to build.
4. CPU time. Consumes about x%.
5. Source layout.  Akubra hash storage, using the pattern "#/##/##" for both datastreams and objects.
6. OCFL storage:  Pairtree.  It will be good when the OCFL storage profile specification is set and incorporated into migration-utils, so that we can define the OCFL layout, similar to how we can specify the Akubra filesystem layout.

Issues

Migration Tests

UW Digital Collections Center Production Repository

Fedora 3: Approx. 561,000 objects (382GB): mostly books, pages and still images, with some audio, video, and PDF resources.  Approximately 2.33M datastreams (6.3TB). Content objects have one binary datastream and 5 XML metadata datatstreams.  Container objects have ~5 XML metadata datastreams.  All datastreams are either inline or managed (no external or redirect datastreams).

Fedora 3.8.1.  Migration run on desktop workstation with 4 cores, 8 GB RAM.  CentOS Linux release 8.2.2004 (Core), Intel(R) Xeon(R) Gold 5220 CPU @2.20GHz

Command run:

$ java -jar target/migration-utils-4.4.1-SNAPSHOT-driver.jar --migration-type=FEDORA_OCFL --source-type=akubra --datastreams-dir=/fedora3-prod/fedora/datastreams --objects-dir=/fedora3-prod/fedora/objects --target-dir=/fedora-migration-test --index-dir=/var/tmp/datastream-index