This can get complicated.
File devices, as Paul states, are mostly accessed sequentially.
But, as has been also said, the actual file volumes may be fragmented on
the filesystem, resulting is effective random access.
But, also, TSM may/probably will be accessing multiple file devices
concurrently. This can also result is effective random access.
But, also, also, if you are using a disk array you also need to take into
consideration the lun layout.. Most big disk arrays share spindles among
multiple servers (wide stripping).
Unless you have a a single tsm task accessing a single file device (that is
not fragmented) on a dedicated disk, then there will contention for I/O's.
Rick
Paul Zarnowski
<psz1 AT CORNELL DOT EDU
> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: Lousy performance on new
6.2.1.1 server with
SAN/FILEDEVCLASS storage
10/20/2010 02:19
PM
Please respond to
"ADSM: Dist Stor
Manager"
<[email protected]
.EDU>
I/O to devclass file volumes will be inherently sequential, yes. It's not
an absolute, however. There are varying degrees of "sequentialness".
Think about it this way. When you are writing these volumes, they will
definitely be purely sequential. However, when reading them, they may or
may not be purely sequential. If you are only restoring say "active"
backup files, then TSM would be skipping over the "inactive" files that can
be interspersed between the active files. Yes, they may have been "active"
when they were written (depending on what did the writing - client or
migration), but by the time you go to read the data, depending on what is
doing the reading you may not be reading them purely sequentially. Even if
you are not reading them purely sequentially, I believe you will still
likely reap benefits by having the blocks laid down on disk sequentially.
Note than when I say laid down on disk sequentially, this includes the idea
of striping the blocks across spindles (if you are doing striping).
Striping does not defeat the sequentiality.
..Paul
At 02:11 PM 10/20/2010, Hart, Charles A wrote:
>Dumb statement, but isn't the whole Idea of the File Devclass is it is
sequential. Can one be more sequential than the other? If its not then
its random.
>
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Zarnowski
>Sent: Wednesday, October 20, 2010 1:07 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] Lousy performance on new 6.2.1.1 server with
SAN/FILEDEVCLASS storage
>
>How you connect to the disk storage (i.e., SCSI or SAN) doesn't matter.
This goes more to the issue of how blocks within the volumes are laid out
on the spindles. formatting them one at a time will cause the blocks to be
laid out in a more sequential fashion, so that when TSM references the
blocks, they will be referenced in a more sequential fashion (assuming you
are doing mostly sequential I/O).
>
>..Paul
>
>
>At 02:02 PM 10/20/2010, Zoltan Forray/AC/VCU wrote:
>>Thanks for the affirmation. This is what I have been
seeing/experiencing.
>> As soon as I can empty the stgpool (5TB), I will define fixed volumes
and
>>see how much difference that makes. I am aware of the issue of
>>single-threading the define/formats to not fragment them, however I
>>wonder how much that really matters in a SAN?
>>Zoltan Forray
>>TSM Software & Hardware Administrator
>>Virginia Commonwealth University
>>UCC/Office of Technology Services
>>zforray AT vcu DOT edu - 804-828-4807
>>Don't be a phishing victim - VCU and other reputable organizations will
>>never use email to request that you reply with your password, social
>>security number or confidential personal information. For more details
>>visit http://infosecurity.vcu.edu/phishing.html
>>
>>
>>
>>From:
>>Markus Engelhard <markus.engelhard AT BUNDESBANK DOT DE>
>>To:
>>ADSM-L AT VM.MARIST DOT EDU
>>Date:
>>10/20/2010 09:20 AM
>>Subject:
>>[ADSM-L] Lousy performance on new 6.2.1.1 server with SAN/FILEDEVCLASS
>>storage Sent by:
>>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>>
>>
>>Hi Zoltan,
>>
>>my experience has been: use fixed size preformatted volumes, and be
>>sure to format them sequentially, even if it seems to take a hell of a
>>time. But then, it´s a one-time action and highly automated, so just
>>don´t try to boost "performance" here. Make sure no one else is bogging
>>perfs, SAN guys sometimes tend to put all kinds of unassorted loads on
>>one storage array producing massive hot-spots during TSM activities.
>>
>>Kind regards,
>>
>>Markus
>>
>>
>>--
>>Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>>Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
>>E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
>>Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie
>>die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist
nicht gestattet.
>>
>>Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko
>>der Verbreitung virenbefallener Software oder E-Mails zu minimieren,
>>dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge
>>an dieser Nachricht durchzuführen. Wir schließen außer für den Fall von
>>Vorsatz oder grober Fahrlässigkeit die Haftung für jeglichen Verlust
>>oder Schäden durch virenbefallene Software oder E-Mails aus.
>>
>>Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden,
>>dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann
>>nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Bank
>>ausgelegt werden.
>>______________________________________________________________________
>>
>>This e-mail may contain confidential and/or privileged information. If
>>you are not the intended recipient (or have received this e-mail in
>>error) please notify the sender immediately and destroy this e-mail.
>>Any unauthorised copying, disclosure or distribution of the material
>>in this e-mail or of parts hereof is strictly forbidden.
>>
>>We have taken precautions to minimize the risk of transmitting software
>>viruses but nevertheless advise you to carry out your own virus checks
>>on any attachment of this message. We accept no liability for loss or
>>damage caused by software viruses except in case of gross negligence or
>>willful behaviour.
>>
>>Any e-mail messages from the Bank are sent in good faith, but shall not
>>be binding or construed as constituting any kind of obligation on the
>>part of the Bank.
>
>
>--
>Paul Zarnowski Ph: 607-255-4757
>Manager, Storage Services Fx: 607-255-8521
>719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
>
>This e-mail, including attachments, may include confidential and/or
>proprietary information, and may be used only by the person or entity
>to which it is addressed. If the reader of this e-mail is not the intended
>recipient or his or her authorized agent, the reader is hereby notified
>that any dissemination, distribution or copying of this e-mail is
>prohibited. If you have received this e-mail in error, please notify the
>sender by replying to this message and delete this e-mail immediately.
--
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
