| From: MOVIES::PLAYFORD "Kevin @ EDO-13 [DTN:824-3394] 29-Jan-1997 1649 +0000" 29-JAN-1997 12:20:35.04
To: EVMS::HUSOVSKY
CC: PLAYFORD
Subj: RE: A few questions
Some answers:
1. Yes. The SnappyDisk from which the snap was created still exists in the
pool. It just isn't mounted and available as a device.
2. I think the question you're asking is:
Can SD$UNBIND unbind the root volume APPL while the snap volume SNAP
remains mounted?
In which case the answer is yes for the same reason as 1. The mapping
information maintained by SCD still indicates that the data exists in the
pool.
However, if your question is:
Can SD$DELETE_DISK delete the root volume APPL while the snap volume SNAP
remains mounted?
The answer would be no for SCD Version 1.0. SCD would need some way of
modifying its mapping information to indicate that the snap was now the sole
owner of segments in the original SnappyDisk, APPL, rather than a shared
owner.
In the longer term we want to be able to do this - it effectively provides a
rollback feature. For example,
a. take a snap of a user disk
b. run my overnight batch job on the data disk
c. ooops, the batch job hosed my data so delete the SnappyDisk and make
the snap my new root.
3. Similarly, for this I think you're asking:
Can SD$UNBIND unbind the root volume APPL while the snap volume SNAP is
dismounted but still bound (no one has called SD$UNBIND on SNAP)?
Again the answer is yes. The mapping informatin maintained by SCD still
indicates that the data exists in the pool.
However, if the question is:
Can SD$DELETE_DISK delete the root volume APPL while the snap volume SNAP is
dismounted but still bound (no one has called SD$UNBIND on SNAP)?
The answer would be no for SCD Version 1.0 for the same reason as 2. above.
The logical steps in creating a SnappyDisk are:
1. SD$CREATE_POOL - create the SCD container file and metadata file on a set
of storage units. Currently this function also binds and exports the pool
device. We're thinking of separating the bind/export functionality from this
command. So you would do a SD$CREATE_POOL and then a SD$BIND_POOL.
2. SD$BIND_POOL - bind together and export the storage units as a device,
usually DGPx. This step should occur on every reboot.
3. SD$CREATE_DISK - create a SnappyDisk in the pool.
4. SD$BIND_DISK - bind and export the created SnappyDisk as a device, usually
DGDx. This step should occur on every reboot once the SnappyDisk had been
created.
5. SD$CREATE_SNAP - create a snap of an existing SnappyDisk. The SnappyDisk
does not need to be bound or mounted to create the snap.
6. SD$BIND_DISK - bind and export the created snap as a device.
Then to reverse the operations:
1. SD$UNBIND - unbind the device from the snap.
2. SD$DELETE_DISK - delete the snap from the pool.
3. SD$UNBIND - unbind the device from the SnappyDisk. Note it is this step
which can be done while snaps based on the SnappyDisk being unbound are still
bound/exported and mounted.
4. SD$DELETE_DISK - delete the SnappyDisk from the pool.
=============================================================================
From: EVMS::HUSOVSKY "Vince Husovsky DTN 381-2506" 29-JAN-1997 16:38:54.19
To: MOVIES::PLAYFORD
CC: BARBARA,PAUL
Subj: A few questions
Hi Kevin,
A few questions came up from Paul working on the server design regarding the
SD$DELETE_DISK function. We are working from the mid-December version of the
SCD FS.
Given that DGA1 is root volume APPL, and DGA2 is snap volume SNAP:
1. Can a VMS user dismount APPL while SNAP remains mounted?
2. Can SD$DELETE_DISK unbind the root volume APPL while the snap volume
SNAP remains mounted?
3. Can SD$DELETE_DISK unbind the root volume APPL while the snap volume
SNAP is dismounted but still bound (no one has called SD$DELETE_DISK
on SNAP).
If nothing prohibits deleting a root disk while a snap is still mounted/bound,
then we will have to accommodate this in the Argus server.
|