Convert to ODS-5

[Peter Zeiszler]

I am investigating converting volumes to ods-5. The situation is that I have a shared shadowed disk that contains files such as rightslist.dat, sysuaf, operator log. The disk is shadowed and mounted on all cluster members. I have a downtime window to do some work on the cluster and thought now would be a good time to convert it. The set volume command wants the disk mounted Privately. "-SET-W-NOTPRIVATE, device must be mounted privately"

I was considering shutting down the cluster and booting one system minimum and redefining OPC$LOGFILE_NAME. Then I could mount the volume privately and do a set volume.
Do I need to do this on both volumes of the shadow disk?
Should I set it on one and init the other and let it perform a shadow copy?
Would it be safer overall to just boot from the CD and perform the convert?
What are the opinions or ideas?

[Andy Bustamante]

I would a node from CD and perform the set volume. You'll need to include /OVER=(SHADOW_MEMBERSHIP) in the mount command.

Do one disk, make sure your startup mounts the shadow set with that volume and adds remaining drives.

Andy

[John Gillings]

Peter,

A safer approach... I'd suggest creating a whole new shadow set with new drives. INIT as ODS-5 and /LIMIT, with a reasonable /HEADERS and any other hints to help the filesystem. This can be done at any time, without eating any of your downtime window. When it's all set correctly, make sure the source disk has all files closed (or boot from CD) and use BACKUP/IMAGE/NOINIT to move the contents.
You now have an upgraded, defragged, clean copy of your data, AND you still have an immediate fallback if anything goes wrong. If you do DSA to DSA you won't have to wait for the shadow copy to complete.

[John Gillings]

Oh, and if you're really short of downtime... you can do this almost "online".

Create your new shadowset as before, while still online, use BACKUP/IMAGE/NOINIT/IGNORE=INTERLOCK to copy the data. Make sure you note all the files that generate access conflicts. These can then be copied using CONVERT/SHARE, or during your downtime window (much quicker if you're only copying the files that were open).

[Peter Zeiszler]

My actual downtime on this one is strange - I actually get as much time as I want. I get a whole day and if things are messed up I have the weekend. I was told of the possible downtime last week and was investigating what I needed to add itaniums to this cluster. Getting a shared ods-5 disk was one of the activities. I was thinking of just putting in a request for new volumes and then migrate files as needed. Doing a convert just means I can get it out of the way sooner without increasing quantity of volumes.

Don't have the spare disks available to init a new volume set at this time. I would have to get additional volumes added to do that which takes alot more time and paperwork.

We always run weekly defrag on this one volume in particular. There are always files locked open but I know it gets most of the files.

[Hoff]

If V7.3-2 or later and already pulling the disk(s) off-line, also consider enabling dynamic volume expansion (DVE).

[Andreas Vollmer · Accepted solution]

Hello Peter,
The attachment contains a sample script of how this task maybe can be solved.
Attention, this is a sample - you must adapt it to your environment and TEST BEFORE use at in the production.
You mentioned that you have a shadowset of the system disk. If it is a "full member" - 2 members at least - and NOT a "low cost" shadowset then you have some options.

I would do following to solve this task:
1) Backup the system disk
2) Boot from a V8.3 CD
3) Mount one shadowset member with MOUNT /OVER=(SHADOW,ID)
4) Now you can run the mentioned script (via cut & paste from the terminal emulation). This will INIT the other shadow member and backup from the original system disk.
No CONVERT/SHARE is needed ;-)
5) Dismount the disks
6) Shutdown the CD 'installation'
7) Boot the new system disk (it will be a single member shadowset if you not have somewhere a mount command in the startup - normally not needed)
8) Check & test the system
9) If convenient - mount the preserved system disk as second member to the shadowset.
10) finish
In case of problems you can always boot from the preserved system disk and start again and you have another backup in your backup solution.

Despite the generous maintenance window, I assume you have other interests as only working ;-))

I hope me ideas are inspiring.
Regards
Andreas

[WWarren]

I have done the same sort of thing several times during the past 6 months, only the disks involved didn't have open files on them so I didn't need to boot a stand-alone environment, and I had plenty of spare disk space to work with. As detailed by others, I'd recommend backing up the disk, reinitializing the shadow set, and then restoring. I don't have the log for a dual-member shadow set, but I've attached the log for a single-volume, which is the same procedure execpt for the additional $ INIT/ERASE and another disk on the $ INIT/STRUCT/SHADOW=() command. Hope you find it useful!

[Jan van den Ende]

And certainly, if you are able to follow Wwarren's procedure, do NOT forget Hoff's advice:
Use THIS opportunity to decide on
-desired cluster size
-maxfiles
-potential disk extension /SIZE
.. and investigate/evaluate ANY INIT params that are no longer modifiable on mounted disks.

NOW is the time to get those right!

Proost.

Have one on me.

jpe