Hi Steve:
I was just about to reply to this post!
We see the same results as you - I asked the presenter of Disk Only
Backups this question and he agreed he saw the same results:
------------------------------------------------
Tim,
I did the same test on my AIX server and saw the same behavior that you
described. It does appear that TSM is deleting the file and rewriting
it. So the dsmfmt does not give any benefit from a fragmentation
standpoint. I did my test on a 5.2.2. server and have not had a chance
to try it on a 5.3 server yet, although I don't have any reason to
believe it will behave differently on 5.3.
Thanks for pointing this out.
David Daun, IBM Green Bay
Tivoli Storage Manager
Advanced Technical Support
920-756-9022 - djdaun AT us.ibm DOT com
"Rushforth, Tim" <TRushforth AT winnipeg DOT ca>
"Rushforth, Tim" <TRushforth AT winnipeg DOT ca>
12/10/2004 04:14 PM
To
David Daun/Green Bay/IBM@IBMUS
cc
Subject
Disk only Backups Technical Exchange
Hi Dave:
In the recent Technical Exchange - "Disk Only Backup Solutions", you
stated the following:
FILE device classes see only two types of fragmentation:
*Filesystemlevel -this occurs as the operating system allocates and
frees space for Storage Pool Volumes within the filesystem. Reclamation
tends to relieve this fragmentation. You can use dsmfmt to pre-allocate
volumes and minimize this type of fragmentation
The test below was done recently by a member of the ADSM list. Does
dsmfmt actually buy us anything here? It appears the the file will end
up in multiple fragments because of the way TSM grows these volumes.
These tests were done on the Windows Platform.
Thanks,
Tim Rushforth
City of Winnipeg
trushfor AT winnipeg DOT ca
---------------------------------------
I did a small scale test today. Below is what I found.
DEFINE DEVCLASS sata01 DEVTYPE=FILE MOUNTLIMIT=10 MAXCAPACITY=2g
SHARED=NO DIRECTORY=l:\adsmdata
DEFINE STGPOOL prod_satapool sata01 ACCESS=READWRITE COLLOCATE=NO
MAXSCRATCH=0 REUSEDELAY=8 MIGDELAY=90 MIGCONTINUE=YES COPYCONTINUE=YES
CRCDATA=NO DATAFORMAT=NATIVE
dsmfmt -data C:\ADSMDATA\SATA0001.DSM 2000 dsmfmt -data
C:\ADSMDATA\SATA0002.DSM 2000 dsmfmt -data C:\ADSMDATA\SATA0003.DSM 2000
dsmfmt -data C:\ADSMDATA\SATA0004.DSM 2000 dsmfmt -data
C:\ADSMDATA\SATA0005.DSM 2000
DEFINE VOLUME prod_satapool C:\ADSMDATA\SATA0001.DSM ACCESS=READWRITE
wait=yes DEFINE VOLUME prod_satapool C:\ADSMDATA\SATA0002.DSM
ACCESS=READWRITE wait=yes DEFINE VOLUME prod_satapool
C:\ADSMDATA\SATA0003.DSM ACCESS=READWRITE wait=yes DEFINE VOLUME
prod_satapool C:\ADSMDATA\SATA0004.DSM ACCESS=READWRITE wait=yes DEFINE
VOLUME prod_satapool C:\ADSMDATA\SATA0005.DSM ACCESS=READWRITE wait=yes
After the dsmfmt I had five files in the C:\ADSMDATA folder that were
each 2,048,000 kb. TSM q vol showed five files with 0 space and empty
status.
I issued a move node command. During the move node w2k shows the file
starting small and getting bigger so it does look like TSM deletes and
reallocates the file. After reallocation the size changed to 2,097,152
kb. Once the move node was complete here is what TSM shows via q vol:
C:\ADSMDATA\SATA0001.DSM PROD_SATAPOOL SATA01 2,048.0 100.0 Full
C:\ADSMDATA\SATA0002.DSM PROD_SATAPOOL SATA01 2,048.0 100.0 Full
C:\ADSMDATA\SATA0003.DSM PROD_SATAPOOL SATA01 0.0 0.0 Empty
C:\ADSMDATA\SATA0004.DSM PROD_SATAPOOL SATA01 2,048.0 66.1 Filling
C:\ADSMDATA\SATA0005.DSM PROD_SATAPOOL SATA01 2,048.0 100.0 Full
Windows shows:
12/10/2004 12:29p 2,147,483,648 SATA0001.DSM
12/10/2004 12:34p 2,147,483,648 SATA0002.DSM
12/10/2004 12:13p 2,097,152,000 SATA0003.DSM
12/10/2004 12:45p 1,420,072,356 SATA0004.DSM
12/10/2004 12:21p 2,147,483,648 SATA0005.DSM
It appears that fragmentation could be an issue.
I went a bit further and set the MAXCAPACITY down to 1g and found that
the files would not grow beyond a 1g size. Then I set it to 3g and found
that the file would expand to 3g before going to the next file. It would
appear that initial dsmfmt really doesn't buy anything.
----------------------------------
-----Original Message-----
From: Steve Bennett [mailto:steve_bennett AT ADMIN.STATE.AK DOT US]
Sent: Monday, February 14, 2005 9:53 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Fragmentation problems with large disk only stogare pool?
Eric and Jean,
I'm not sure that is true. I did some limited testing in a win2000 sp4
tsm 5.2.3.2 and IIRC it appeared that the preallocated files did get
reallocated at the os level the first time they received data and I
would assume when they were reclaimed and reused. We just started using
a 6.4 gb sata and are not using the preallocated files at this time.
Can anyone else validate what I think I saw vs what Eric saw?
Loon, E.J. van - SPLXM wrote:
> Hi Jean!
> We are currently designing a new TSM environment with a disk-only
> implementation.
> Because of the risk of fragmentation, we decided to use pre-allocated
file
> volumes. This prevents fragmentation, because the volumes are
propperly
> reclaimed while the actual OS file is not physically relocated.
> Kindest regards,
> Eric van Loon
> KLM Royal Dutch Airlines
>
>
> -----Original Message-----
> From: William Jean [mailto:wjean AT GLASSHOUSE DOT COM]
> Sent: Monday, February 14, 2005 14:55
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Fragmentation problems with large disk only stogare pool?
>
>
>
>
> Has anyone who is using a large disk only primary storage pool run
into any
> problems with fragmentation?
>
>
> **********************************************************************
> For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect
or incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
> **********************************************************************
>
--
Steve Bennett, (907) 465-5783
State of Alaska, Enterprise Technology Services, Technical Services
Section
|
