From:
                                                                    11:04 AM
Subject: Snapshot services for OVMS

I've been thinking about Jon Pinkley's post about the
snapshot facility and its price, which is kinda high. Snapshots
is a technology that many will feel some reluctance to try because
it involves (in essence) adding another filesystem below the
current one and making the storage model more complex. Safety and
some of my other stuff suffers the same disadvantage, as does HSM.

While I have no inside info about what the code looks like,
I believe that it requires some kind of simple meta filesystem
underneath the one that is presented to VMS. (Remember: the O in
OVMS is silent.) (:-) ) Until you make a snapshot, it won't do
much, but gradually it must manage "moved blocks" and it has
to keep them somewhere. The package does however use one or two
layers of virtual devices, which supports my conjecture.

No solution of this type really can do any better than a shadowing
disk where you break the shadow set; if the disk is not dismounted
you get a snapshot of the state of the disk at some time, but
there is no guarantee that dbms transactions that might require
several disk accesses might not be left in a partially done state.

Supposedly you need less disk for this than for a full blown
shadowset, which is good, but if you take a bunch of snapshots
the underlying meta-filesystem may get fragmented and slow things
down, or eat a potentially unbounded amount of disk. So the thing
should be really useful where a short dismount/snapshot/mount can be
done, backup taken, and the snapshot erased. Whether the thing
fragments in the meta file system underneath as you do this repeatedly
I have no idea. I might ask in L.A.

There is a possible way to do it differently. Let me suggest it.
(This might, BTW, be entirely usable on OSs other than VMS.
This will ensure the idea was published first so no Johnnie-
come-lately will be able to patent it or otherwise block its
use.)

Specifically, if the idea is to get a backup that is an image of a disk
at some time t, another way to do it is to start a backup on a
virtual disk that logs writes to it at time t-b, where the
backup time is b, and record the log of all writes between time
t-b and time t. I gave away all or most of a logging virtual disk
awhile back that would do the logging part. The result would
be you'd have a backup of the disk plus what was needed to update
it to the end of the backup period so it would be an accurate
snapshot as of that time. The virtual disk records logical blocks
though so one would have to use back/phys to be able to play the
log forward. However one could have such a driver root thru the
FCB chain to find what files were being written to and record
virtual block number and file ID. (It'd be necessary to look at
the WCBs too.) Then normal backup could be used. Funny I never
bothered with that mod. Would have been more useful.

If one dismounts the disk AFTER the backup in this scheme, note,
one gets the log ending at a point where the disk is dismounted
and everything's clean. So it really has all the advantages of
the DEC scheme, no underlying file system, can be inserted pretty
transparently onto an existing disk, and won't fragment at any
meta level. Hoo boy. And most of the work is done and in the
public domain.

Someone would just need to do the LBN to FID/VBN bit if one wanted
to use other than backup/physical.
glenn
everhart@gce.com