Well, here's hoping Steve can get the price down some. 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. 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 can get fragmented and slow things down, or eat a potentially unbounded amount of disk. So the thing is 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 Steve if I see him in L.A. Of course, 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. Jon Pinkley wrote: > > >Well, I expect to be at LA, will be giving a technical session > >of my own too. (Twice, yet! Wed, and Thurs). > > > >I agree that the snapshot service thing's way overpriced. Someone > >can't seem to get out of his mind that there might be 3 or 4 customers > >in the world for it at high prices. Price it lower and maybe some > >of the folks could afford it. > > I did get a response from Steve and he says they will take it to > management and see what comes out of it. > > He said to say Hi to you. > > >Personally I suspect you'd be better off playing back/phys games > >and using my hack to read files back off the tapes if you need > >them. > > I suppose that is a possibility, but it requires dismounting the > volume for an extended period of time, and the fastest tape drive > we have is TZ87 (DLT2000) class (~1.1 MB/s). If we had a DLT7000 > that would improve things. > > We do have the capability to split mirrors on the HSZ, but there > isn't a clean way to do this from a DCL script (at least I don't > have a good way). HSZTERM is unsupported and seems to have SMP > problems. We have had three weird HSZTERM induced problems that > required rebooting. Seemed to be interfering with some low level > logical name stuff like redefining lnm$file_dev although I am not > sure what the problem was. It has only happened on our multiprocessor > 2100A, not the uniprocessor. Perhaps setting affinity to the primary > CPU while running HSZTERM would prevent the problem. Right now I > have my own program in the SMP specific root that just writes > "not safe to run SET HOST/SCSI from this node" and exits. > > > The NT disk services folks did look my thing over and liked > >it...it worked perfectly for them...but snapshot services was > >a kind of last gasp from Scotland to salvage something out of > >Spiralog. I will describe in my talk some of what they should > >have salvaged. They could very easily have grafted the spiralog > >directory scheme onto ods-5 with the hacks I proposed and > >had a system where huge directories didn't penalize you, since > >spiralog directories are b-trees. > > Sounds like that would have been a nice addition, as would some of the > TOPS things like DELETE/UNDELETE/EXPUNGE and perhaps a hidden attribute. > > Do you know they have ever implemented a reference count for file > headers, so there wouldn'd need to be a set file/remove vs delete. > Seems that is one thing they should have borrowed from Unix (or perhaps > some even earlier o/s). > > Snapshots will, I predict, > >slow way down as you take many. > > You are evidently implying that if a parent has many children > that when a copy out operation is performed, it is copied to each > child instance, instead of to a single pool location that each of > the children will then reference. I will ask Steve about this. > > Another thing I am going to ask him is how how the ucb busy bit is > handled. I.e. will the snapshot driver become a serialization point > in the i/o path, or does it do something like MSCP to try to allow > optimation to occur at the disk or some other location in the underlying > pool storage. > > > > >glenn > > Talk to you later. BTW, what are your talks about? Are they on the > DECUS website under session at a glance? > > Jon