ADSM-L

Re: TSM DB/Disk Pool - Disk tuning question

2001-08-30 17:50:44
Subject: Re: TSM DB/Disk Pool - Disk tuning question
From: Jeff Bach <jdbach AT WAL-MART DOT COM>
Date: Thu, 30 Aug 2001 16:51:30 -0500
I see this on 4.1.3.0 Server code.  It actually looks like one transaction
per volume (as opposed to one file) , then go tot the next volume.  I say
this because for small files, it appears to not change volumes for each
file.

Anyone else?

Jeff Bach
Home Office Open Systems Engineering
Wal-Mart Stores, Inc.

WAL-MART CONFIDENTIAL


        -----Original Message-----
        From:   asr AT UFL DOT EDU [SMTP:asr AT UFL DOT EDU]
        Sent:   Thursday, August 30, 2001 4:22 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: TSM DB/Disk Pool - Disk tuning question

        => On Thu, 30 Aug 2001 15:56:48 -0400, Lindsay Morris
<lmorris AT servergraph DOT com> said:

        > Jeff, clever! run iostat, then watch sessions start and land on
different
        > physical disks, on by one.
        > Like the idea.

        Note; the sessions do not grab and keep individual volumes;  They
appear to
        walk down the list of volumes, one file at a time.  This is easiest
to see if
        you can arrange to back up a big dir full of ~500M files. (CDROM
ISOs or such)
        you can watch disk activity walk down the list of disks.


        > But what happens when you run out of volumes? Say you have 8 disk
volumes,
        > and 9 sessions.  Does the ninth session just hang, until one of
the first 8
        > finishes?  Or does the ninth session grab some busy volume,
sharing it with
        > another session?

        Going out on a limb, speaking from the perspectiove of a client
service
        thread:

        - I've got a new file to write.
        - I get in line for a volume.
        - I walk up the queue.
        - I get priority on a volume
        - I write my file.
        - I wait for my remote client to be ready to give me another file.

        So, the volumes are instantaneously locked at the file granularity.

        Of course, I'm just making this up, so don't bank on it.  But it
matches the
        behavior I've seen so far.

        - Allen S. Rout


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to
whom they are addressed.  If you have received this email
in error destroy it immediately.
**********************************************************************
<Prev in Thread] Current Thread [Next in Thread>