Re: Mounting identically labelled disks (OVMS73)

From: JF Mezei (jfmezei.spamnot_at_istop.com)
Date: 01/16/04 

Date: Fri, 16 Jan 2004 17:40:17 -0500

News Reader wrote:
> $ ! change the label of the privately mounted backup disk and remount /sys
> $ set volume /label:REGNUM_BACK2 dad20:
> $ umount DAD$REGNUM_BACKUP2
> $ bind /system /write /connect REGNUM_BACKUP2
> %LADCP-I-CONNAVAIL, successful connection to service REGNUM_BACKUP2
> %LADCP-I-BIND, service bound to logical unit DAD$REGNUM_BACKUP2 (_DAD22:)

Not sure what umount does. The correct command is "dismount". Also, if you are
in a cluster and the drive has been mounted by other nodes, you need to do
DISMOUNT/CLUSTER to make sure the cluster has completely forgotten about that drive.

> $ mount /noassist /system /write DAD$REGNUM_BACKUP2 REGNUM_BACK2
> %MOUNT-I-MOUNTED, REGNUM_BACK2 mounted on _DAD22:

You should try SHOW DEV DAD22:/FULL at this point. This will provide much
information on what VMS thinks it is. It should be owned by SYSTEM, and
protection should be:

S:RWPL O:RWPL G:R W:

But based on the information you provided after, it looks like the problem
isn't with the VMS file system or VMS devices, but rather the container file system/NFS.

And yes, the error message from the ANALYSE/CONTAINER/REPAIR is strange
considering it supposed to fix the problem it is complaining about.

Have you considered moving teh container system back to the original drive,
create an empty one on the new drive, map both to some unix client and use
unix commands to copy from the old container to the new one ?

Seems that the design of the container file system is extremely tied to the
VMS device and file system (the doc mentions that it is tied to file-id so if
you restore from backup without /IMAGE, the restored files won't have the same
IDs, but that is *supposed* to be fixed by ana/container/repair. 








Relevant Pages
    

  • [RFC] [PATCH] OCFS2
    ... This is OCFS2, a shared disk cluster file system which we hope will be ... Included in OCFS2 is a small cluster stack. ... 
    (Linux-Kernel)
  • Re: Partition Magic Incompatibility??
    ... manual repair etc. are still abysmal for NTFS. ... FATxx, rather than anything inherent in the file systems. ... MS'a approach to file system maintenance seems to assume that the ... - a directory entry that points to the cluster chain ... 
    (microsoft.public.windowsxp.general)
  • Re: Multiple servers access to single shared resource point
    ... There are nurmous cluster filesystems that will work for your solution. ... It is a storage software issue. ... silly to buy the PanFS file system, ... servers, with access to the data either being through the data ... 
    (comp.arch.storage)
  • Re: Speaking of Clusters:
    ... As I understand it, the basic capability that Veritas Cluster Server provides is a cluster-wide file system, which is a prerequisite for any sort of failover capabilities within a cluster, and some support for application failover operations between nodes. ... No, it wouldn't have shared storage at the same level that VMS does, but then again it wouldn't require storage that costs nearly as much as shared VMS storage does. ... 
    (comp.os.vms)
  • Re: CHKDSK killed my OpenGL subsystem
    ... >> sanity of the file system. ... NTFS would prevent this from happening. ... As to "no FAT"; well, the information about which cluster comes next ... 
    (microsoft.public.windowsxp.general)