It's a bad idea to mix block sizes, especially if you share media pools.
You will see status 84 errors with a message like this:

Error bptm (pid=29350) FREEZING media id xxx123, too many data blocks
written, check tape/driver block size configuration

So, if you are using SSO, and all of your media servers aren't at the
same block size, that could be bad.  Or if you have NDMP hosts that
write at a different block size than your media servers, this problem
will crop up as well.

When you change SIZE_DATA_BUFFERS, it is a global change.  All data
written to tape will be written in sizeof(SIZE_DATA_BUFFERS) bytes.
It's like using tar to write directly to tape; you can specify a
blocking factor (you can do this when writing to a regular file as
well), that's exactly what that setting does.

-- nick

Hi all,

We are looking at tuning SIZE_DATA_BUFFERS and NUMBER_DATA_BUFFERS to keep our
LTO{2,3} drives streaming, however, an interesting question has come up within
our storage group.

Since we interleave blocks from various hosts (grouped by "windows", "unix",
"Exchange", "Oracle", "Sharepoint", etc etc) and the block size will potentially
differ when we implement the "SIZE_DATA_BUFFERS" tuning parameter, will this
cause issues when it comes to doing restores (reading the tapes) ? i.e. some
blocks on the tape will be 64KB and other blocks will be 256KB.

What are the implications of the aforementioned and is it bad practice ? And is
there and authoritative method to deal with mixed block sizes written to tape ?

 -aW
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu