ADSM-L

Re: DIRMC - Are copypool reclamation performance issues resolved or not.

2005-03-17 07:39:37
Subject: Re: DIRMC - Are copypool reclamation performance issues resolved or not.
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 17 Mar 2005 07:38:16 -0500
Jurjen -

In this thread, and the "Minor gotcha on upgrade to 5.3" thread, you
indicate that TSM 5.3 has changed things such that "...the handling of
FILE volumes was changed. All writes to such a volume is now done in
blocks of 256 KiB minimum...". Could you provide a documentation or web
site reference for that 5.3 change?

The only "256 KB" related change that I can find in 5.3 is a
Windows-specific, tape-only maximum block size change (max: 256 KB),
controlled by a new DSMMAXSG utility for tweaking Host Based Adapters.
(ADSM/TSM always used a maximal tape drive block size on Unix systems,
but Windows was problematic.) This is documented in the TSM 5.3
Technical Guide redbook, as well as the TSM 5.3 for Windows Admin Ref
and Admin Guide manuals.

According to 2004 Technote 1167281, the block size for FILE and DISK
devtypes has been a fixed size of 256 KB for some time.

I'd like to see definitive information on this before committing my 5.3
beliefs.

   thanks,  Richard Sims

On Mar 17, 2005, at 2:29 AM, Jurjen Oskam wrote:

On Wed, Mar 16, 2005 at 07:29:50PM -0600, Rushforth, Tim wrote:

        [DIRMC]
What in 5.3 warrants new consideration?

Probably the fact that sequential volumes are written to in blocks of
at
least 256 KB, even when the data is only 1500 bytes. This can cause a
lot of
overhead, and the effective capacity of sequential volumes could be
reduced
by a factor of 60 or more.

Note that a great number of factors influence the above statement. On
the
one end, it could cause a perfectly OK setup under 5.2 to be unusable
under
5.3. On the opposite end, you might notice no adverse effects and even
experience a performance improvement.


In the case of FILE storagepools used as a DIRMC destination, you
might find
yourself in the first scenario (works under <= 5.2, doesn't work under
5.3). You might be able to alleviate this by adjusting the TXNGROUPMAX
server setting and the TXNBYTELIMIT client setting. Unfortunately, this
doesn't affect data that's already in a storage pool. And unfortunately
again, storagepools used as DIRMC destination often have quite generous
retention settings, as per the documentation and general
recommendation.
Part of the reason that these retention settings could be generous was
that
directories were so small that it wouldn't matter a lot. With the new
handling of sequential volumes, it does start to matter (and sometimes
a lot).

--
Jurjen Oskam

<Prev in Thread] Current Thread [Next in Thread>