Removal of Redundant SYSn directories on System Disk

[Jefferson Humber]

AXP v.7.3-2

We now have a two node cluster, which started life as a four node cluster.

At the root of the system disk we have four SYSn directories, although only two of them are now used.

Is there an official (clean) way of removing the two redundant SYSn directories to save on disk space ?

Easy 10 points for a seasoned pro. ;-)

Jeff

[Kris Clippeleyr · Accepted solution]

Jeff,

The "official" way to go is:

$ @sys$manager:cluster_config

and then option "3. DELETE a root from a system disk"

But you can also DELETE all files & directories underneath the [SYSx] directory by hand, with the exception of SYSCOMMON.DIR

Greetz,

Kris

[Volker Halle]

Jeff,

@SYS$MANAGER:CLUSTER_CONFIG offers a supported interface to removing a node from a cluster by removing it's root from the system disk.

Volker.

[Jan van den Ende]

Jeff,

if you somehow managed to do the removal partially by hand, there is (was?) a chance that CLUSTER_CONFIG option REMOVE is not successfull.

In that case Kris's solution will help, but is not complete.
His warning about [.SYSCOMMON...] is VERY serious: that is THE ONLY system environment for your CLUSTER!
SYSCOMMON.DIR can be removed with SET FILE/REMOVE, and after that SYSx.DIR is empty and can be deleted.

.. maybe you should check your SYSCOMMON.DIRs
first.
There have been versions of BACKUP where an /IMAGE restore got confused, and CREATED SYSCOMMON.DIR in the first SYSx, and SET FILE/ENTERed it in all other SYSy's, and as VMS$COMMON.DIR in [000000]

DUMP/HEADER SYSCOMMON.DIR, and look for the File Backlink Pointer. It should be to [4,4,0], which is the File ID of each disks'
000000.DIR

If NOT, then DON'T remove! If the real entry is not present, the whole tree will not be present in your image backups!!


hth,

Proost.

Have one on me.

Jan

[Uwe Zessin]

The 'real' entry is often one of [SYS*]SYSCOMMON.DIR - as Jan wrote, check with DUMP/HEADER (I prefer to add /BLOCKS=COUNT=0, just in case that is new to you).

You then 're-'move the old VMS$COMMON.DIR; and put the primary entry back in place. E.g.
$ set default SYSDISK:[000000]
$ rename [000000]VMS$COMMON.DIR;1 BADCOMMON.DIR;1
$ rename [SYS7]SYSCOMMON.DIR [000000]SYSCOMMON.DIR
$ rename SYSCOMMON.DIR VMS$COMMON.DIR

The last step should make sure that the name entry _within_ the file header itself is correct.

$ set file /remove BADCOMMON.DIR;1
$.. make the necessary entry for [SYS7] if you keep that root

Finally, I would check if the volume works with hardlinks and run a verify on it.

Oh, yes, almost forgot: it's always good to run a backup before starting such an 'adventure' ;-)

[Jefferson Humber]

Thanks guys.

I assumed that CLUSTER_CONFIG would be the tool for the job, but wanted to check before I did it.

I haven't touched it yet, so will try after Xmas now I expect.

Will of course take an offline image of the system disk before I start the process. ;-)

Cheers,

Jeff

[John Gillings]

re: Uwe - RENAME can be used to repair *some* variants of the VMS$COMMON/SYSCOMMON backlink errors, but not all! DFU VERIFY/FIX can do them all safely, without needing to anyalyze which variant you've got.

Jeff - realistically, a redundant system root probably doesn't return enough disk space to make it worth while. On a system I just checked, there were only 45 files. Other than the page, swap and dump files, total size 250 blocks (cash equivalent value less than 10 milliseconds of your time!)

On the other hand, a spare root can be handy to boot from in an emergency, or to boot another node into your cluster temporarily.

I'd leave at least one spare root, with moderate sized page, swap and dump files. Use them as a buffer against running out of space on your system disk. A few 100K blocks you can recover very quickly if things get tight.

If you're really short of disk space, just remove the page, swap and dump file to keep you going until you can upgrade the disk.

[Robert_Boyd]

Once upon a time I wrote a command procedure to check and repair the backlinks to VMS$COMMON. This may be of mostly educational value as an interesting command procedure. DFU takes care of most of this now -- I'm providing it as an attachment here. Just convert the name of the file back to .COM

Robert Boyd

[Jan van den Ende]

Jeff,

From your Forum Profile:


I have assigned points to 30 of 87 responses to my questions.


Maybe you can find some time to do some assigning?

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption â My Question(s)â you will find â questions or topics with unassigned points â Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. â nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before â please do not take offence â none is intended!

Proost.