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.
One other important thing to note is that I defined the devclass to use l:\adsmdata while the dsmfmt and defines point to c:\adsmdata. Since it reallocated the files on c rather than l it appears that the full pathing is maintained as desired. I can cut my 6tb sata into three 2tb partitions and predefine 100 files of 20gb on each partition and let TSM do it's thing.
If anyone sees any kind of problem with this methodology either testing or production please let me know.
Rushforth, Tim wrote:
I did a test of predefining volumes with dsmfmt (TSM 5.2.2.4 on NTSF file system on Windows 2003). If the volume is not completely full, the size of the file on disk changes from 20GB (say) to the amount of data used. As more data is migrated later the volume was appended to.
I wanted to test pre-allocating the volumes with dsmfmt (as opposed to just defining them to the storage pool) to try to eliminate file system fragmentation. (If you don't pre-allocate the volumes they continually grow resulting in a lot of file system fragments).
But the result I saw above made me wonder if it was worthwhile. IE after a while all of these pre-allocated volumes would end up in fragments.
But I may be missing something here .... Has anybody else looked into this?
Thanks,
Tim Rushforth City of Winnipeg
-----Original Message----- From: Steve Bennett [mailto:[EMAIL PROTECTED] Sent: Thursday, December 09, 2004 5:34 PM To: [EMAIL PROTECTED] Subject: use of preallocated files in disk stgpool using devtype of file
We are supplementing our existing ATL with a 6TB SATA. Clients will continue to backup directly to the TSM server's local SCSI disk which will get migrated to the SATA stgpool which will migrate to the ATL.
Since our W2K TSM server is limited to 2TB file systems we will be allocating 3 filesystems for the 6TB of space. Because of the single path issue when using dynamically allocated scratch volumes in the SATA pool I intend to define the pool with maxscratch of 0 and preallocate all the the vols with the dsmfmt command and then define all the vols to the SATA pool. So far so good.
In the case of dynamically allocated vols TSM allocates and then increments the size of the vol as needed up to the max size specified. When no longer needed the vol is then deleted so the space can be reused.
When using predefined 20GB vols will TSM append to the end of the vol if it is not completely full just as it does for tape vols or does it go to the next available volume in scratch status? I suspect and hope the answer is the latter but what's the real answer?
TIA
--
Steve Bennett, (907) 465-5783 State of Alaska, Enterprise Technology Services, Technical Services Section
--
Steve Bennett, (907) 465-5783 State of Alaska, Enterprise Technology Services, Technical Services Section
