On Jun 7, 2005, at 10:06 AM, Prather, Wanda wrote:

Hi Richard,

Thanks for responding; maybe this will give you something to amuse
your
brain over morning coffee.

The reason for the question, mgmt here is considering going to all-
disk
backup (for onsite).
So our sequential "volumes" will be disk instead of tape.

We occasionally have issues with mis-classified data ending up on a
tape, and the tape has to be pulled and destroyed.
No big deal with a tape.  Big deal when the "volume" is a 1 TB raid
array!

I would recommend against destroying such RAID arrays - sounds
expensive. :-))

So the question comes, what is the likelihood that we would
contaminate
TWO 1 TB raid arrays with a split file?

I think for sequential volumes, TSM doesn't know that the volume is
full, until it tries to write to it.
If there isn't space for the next "block", then it mounts a scratch
and
rewrites the block to a new tape, yes?

So can I assume that the file would have to be larger than an
aggregate
(what is that, MOVESIZETHRESH?) in order to end up split across 2
tapes?

A magic word in your scenario is "sequential". This means you will be
using
File type devclass. TSM 5.3 allows you to make the volume size
whatever you
want, up to the limits of the file system. A judicious choice will
make for
a size which affords nice capacity while not being ponderous when you
have
to deal with a stray. And I should think that you could deal with the
stray
by doing an Expire or Delete Backup command from the client, perhaps
followed by a MOVe Data ... RECONStruct=Yes on the containing server
volume
if there needs to be assured erasure of the goner. With this, may it
be the
case that concerns over volumes and spanning are unwarranted?

File type devclass volumes may incite more predictive processing in TSM,
given that there is the advantage of known size, whereas the actual
length
of a tape is not known. That is, TSM will probably know there is
insufficient
space for the next Aggregate, or clump of a file whose size is larger
than
an Aggregate, so as to go to a new volume. (Now, I don't know for
certain,
but have to suspect that the File volume's size is uniquely tracked
in the
db rather than simply taken from the devclass spec, given that the
devclass
MAXCAPacity can be updated at will. Thus, the size of volumes over time
should be deterministic.)

If there's definitive doc about all this, I have not yet encountered it.
Someone out there may have more info.

Thanks for lending brain power!

If I were really smart I'd be charging for exposition of what I know,
rather than working for a living.  :-)

    Richard Sims