Table of contents
Background
Starting from a certain Conduant SDK version (uncertain which), the Conduant card firmware has lost its ability to gracefully play back modules that contain one or more corrupt/dead disks. Such modules will either freeze the Mark 5, or will play back extremely slowly with zero data.
Workaround
Disks have to be removed from the module and attached to a server so that the raw disk data can be accessed. One option is to place disks into a Mark6 module and load that into a Mark6. Alternatively, disks can be inserted into server disk cradles.
The disks of the module should appear as blank drives without partitions:
dhcp30222:~ # cat /proc/partitions
major minor #blocks name
2 0 4 fd0
8 0 160836480 sda
8 1 41943040 sda1
8 2 114861056 sda2
8 3 4031343 sda3
11 0 1048575 sr0
8 16 1953514584 sdb
8 32 1953514584 sdc
8 48 1953514584 sdd
8 64 1953514584 sde
8 80 1953514584 sdf
8 96 1953514584 sdg
In the above example, six disks (/dev/sdb to /dev/sdg) are still intact.
A recovery script now found in the DiFX repository (https://svn.atnf.csiro.au/difx/sites/MPIfR/mark5/mark5_scan_recovery.py)
Reverse Engineered Mark5 Disk Structure
A certain H.V. at JIVE has reverse engineered the Mark5 data block structure. Mark5 recordings are scattered as 2^16 -byte sized blocks, written round-robin to disks of a module. Each block has a 8-byte header. The first 4 bytes are unused. The next 4 bytes (32 bit unsigned int) contain a sequence number in the upper 28 bits. The rest of the block contains VLBI data.
The sequences numbers of the blocks allow 1) detection of the original ordering of disks in a module, 2) detection of lost disks (lost blocks).
A certain J.W. at MPIfR spotted the User Directory storage area on the raw disks. The user directory is located at 11272704 bytes before the end of every disk. Each disk should contain an identical copy of the user directory.
Contents of a disk set can be recovered with https://svn.atnf.csiro.au/difx/sites...an_recovery.py
