> I find it hard to believe that cloning preserves multiplexing, it's my
> understanding that nsrclone goes one by one, SSID to the next SSID
> cloning each singly before moving on to the next

It doesn't need to do that (at least not in the situations I've used
it), and it's very easy to test.

Instead of copying one ssid at a time, it can maintain a list of ssids.
As it streams a source volume, data from any matching ssid is copied to
a destination volume.  This has the big benefit of requiring only a
single pass on a source volume.

You can verify the behavior for a test in a few ways:

#1 Watching the I/O throughput.  Assuming a fairly even multiplex mix,
   then a demuxed clone would show a write speed at around 1/n of the
   read speed.  If read and write are equal, then it must be writing all
   the savesets instead of just one.

#2 Examine the mminfo details on the clone fragments.  If its demuxing,
   then each "tape file" will usually only have one ssid.  If
   multiplexing is maintained, then several ssids will be in each tape
   file.

#3 Watch the tape behavior.  This is harder because you can't see it
   all, but demuxing the ssids would require the tape to be rewound
   several times to go back and pick up the old ssids.

-- 
Darren Dunham                                           ddunham AT taos DOT com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER