What does the user community think of this statement by Legato support in regards to cloning?
From Legato support:
I was wrong about clones being de-multiplexed. They're not. One of our design engineers explained it to me as follows:
nsrclone reads the tape and as it encounters each piece of data from the savesets it is cloning, it will write them to the destination tape. This means the data on the destination tape will be multiplexed exactly as it is on the original tape.
This also means that the nsrclone operation only needs to read the tape one time, to process all the savesets on that tape to be cloned.
In order for nsrclone to de-multiplex, it would have to read each saveset one at a time (n passes through the tape), or be able to cache all the savesets and write them to the tape individually - which it doesn't for obvious reasons.
If you write to a file type device (normal or advanced file type) then the savesets are written to disk into individual files, and then cloned to a tape with no multiplexing.
If you write to an optical device, all the savesets are written to the same file, and will be multiplexed on the destination tape.
nsrclone doesn't need the savesets in a certain order. People use mminfo all the time to get data on which savesets to clone, and as far as I know don't need to have them put in a certain order. This would be difficult to do, all the file markers would have to be analyzed and sorted, none of the scripts I've looked at went to this depth. The misunderstanding may come from the fact that when you scan save sets that span tapes, you need to scan the tapes in the correct order.
Regarding the mminfo problem, we played around with it, and it looks like it may have to do with the '-otR -t' sequence. Using that seems to give somewhat random results, although it did work both without that sequence and with -t alone.
Ed Skolnik
The Interpublic Group Of Companies, Inc.
GIS Chicago System Administrator
Chicago, Illinois 60611
From Legato support:
I was wrong about clones being de-multiplexed. They're not. One of our design engineers explained it to me as follows:
nsrclone reads the tape and as it encounters each piece of data from the savesets it is cloning, it will write them to the destination tape. This means the data on the destination tape will be multiplexed exactly as it is on the original tape.
This also means that the nsrclone operation only needs to read the tape one time, to process all the savesets on that tape to be cloned.
In order for nsrclone to de-multiplex, it would have to read each saveset one at a time (n passes through the tape), or be able to cache all the savesets and write them to the tape individually - which it doesn't for obvious reasons.
If you write to a file type device (normal or advanced file type) then the savesets are written to disk into individual files, and then cloned to a tape with no multiplexing.
If you write to an optical device, all the savesets are written to the same file, and will be multiplexed on the destination tape.
nsrclone doesn't need the savesets in a certain order. People use mminfo all the time to get data on which savesets to clone, and as far as I know don't need to have them put in a certain order. This would be difficult to do, all the file markers would have to be analyzed and sorted, none of the scripts I've looked at went to this depth. The misunderstanding may come from the fact that when you scan save sets that span tapes, you need to scan the tapes in the correct order.
Regarding the mminfo problem, we played around with it, and it looks like it may have to do with the '-otR -t' sequence. Using that seems to give somewhat random results, although it did work both without that sequence and with -t alone.
Ed Skolnik
The Interpublic Group Of Companies, Inc.
GIS Chicago System Administrator
Chicago, Illinois 60611