GreenLake Administration
- Community Home
- >
- Storage
- >
- Legacy
- >
- Optical Jukeboxes and Drives
- >
- ghostly importp
Optical Jukeboxes and Drives
1851247
Members
2946
Online
104057
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Knowledge Base
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-11-2002 10:05 PM
02-11-2002 10:05 PM
ghostly importp
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
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
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2026 Hewlett Packard Enterprise Development LP