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 - [EMAIL PROTECTED] "Rushforth, Tim" <[EMAIL PROTECTED]> "Rushforth, Tim" <[EMAIL PROTECTED]> 12/10/2004 04:14 PM To David Daun/Green Bay/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] --------------------------------------- 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:[EMAIL PROTECTED] Sent: Monday, February 14, 2005 9:53 AM To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] > Sent: Monday, February 14, 2005 14:55 > To: ADSM-L@VM.MARIST.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
