ghostly importp

Glenn L. Stewart — Tue, 12 Feb 2002 06:05:52 GMT

A long winded problem - but certainly one everyone should be able to have some input in.
Points certainly awarded for input.

Original problem:
suspect MO due to omniback error.

Seconadry problem:
fsckp did not seem to produce load hence confirmation of MO suspect not performed.

Decision:
To export contents of MO to another replacing the original.

I've had a lot of problem doing so over the past week. I've realised how confusing the world of omnistorage can be at times and have got to a point where I am back where I started but I've lost an MO internally.

The process:
It was recommended that I use sync_media.
I copied data from one MO to one in MO_FREEPOOL using copyp.
This was successful - but I needed to know how to swap this for the other.

I used the following process (see end of man sync_media).

Source: A:5ea56e B:63c974
Destination: A:e51ea7 B:e51ea8

- change the state to EXPORTABLE for the source_volumeID
# chgstate EXPORTABLE source_volumeID
# chgstate EXPORTABLE 5ea56e
Volume 5ea56e/63c974 was successfully changed.

- export the media with source_volumeID from the library
# exportp source_volumeID
# exportp 5ea56e
OK

- remove the media with source_volumeID from the jmd database
# rmplat source_volumeID
# rmplat 5ea56e

- change the state to EXPORTABLE for the mirror_volumeID
# chgstate EXPORTABLE mirror_volumeID
# chgstate EXPORTABLE e51ea7
Volume e51ea7/e51ea8 was successfully changed.

- export the media with mirror_volumeID from the library
# exportp mirror_volumeID
# exportp e51ea7
Unable to export the media.
Export slot not empty

**** NOTE *****
This was not possible because the mail slot was full from first export.
Then I incorrectly performed the following...

# exportp -u e51ea7
OK

This left this MO internally but exported.
Where did it go???
Anyway I continued not realising this yet...

- re-import the media with mirror_volumeID into the library again
-> it will be recognized with the previous used source_volumeID
# importp BoxID
# importp 0
Media imported.
Side A is 5ea56e
Side B is 63c974
(not desired output)

I realised that it imported from mail slot.
I wanted to import the destination (now lost) instead of the source.

Performing a listp -f showed that the exported MO was in none of the slots.
I assumed that it was in the 67th (empty slot) so proceeded to import...

#importp -i 67 -n 0
(import missing MO from slot 67 due to exportp -u e51ea7)
Media imported.
WARNING: Side A has been assigned guest id 6899fb
WARNING: Side B has been assigned guest id 6899fc

Excellent!!! So I thought.
Until I saw this output from listp -r
# listp -r | grep 6899
6899fc 0
6899fb 0

?? Real Volume ID is non existant.

Tried another empty slot:

# importp -i 68 -n 0
Media imported.
WARNING: Side A has been assigned guest id 68ad4b
WARNING: Side B has been assigned guest id 68ad4c

Now left with 2 "Ghost" MO's
Lost data...

# listp -f | grep MO | grep -v hpufs
6899fc MO 0 67 1 0 0 - Inval 0 Y Exportable
6899fb MO 0 67 0 0 0 - Inval 0 Y Exportable
68ad4c MO 0 68 1 0 0 - Inval 0 Y Exportable
68ad4b MO 0 68 0 0 0 - Inval 0 Y Exportable

Note: Inval.

And I still need to copy the MO in question.

Thanks

Glenn

topic ghostly importp in Optical Jukeboxes and Drives

ghostly importp