dsmfmt -m -data filename 2000
is not the same thing as
dsmfmt -g -data filename 2
1000m is not 1g
(At least on AIX. Hopefully this is true on Windows as well.)
[RC]
"Steve
Bennett"
<steve_bennett To
@ADMIN.STATE.A ADSM-L AT VM.MARIST DOT EDU
K.US> cc
Sent by:
"ADSM: Dist Subject
Stor Manager" Re: use of preallocated files in
<ADSM-L AT VM DOT MAR disk stgpool using devtype of file
IST.EDU>
12/10/2004
01:52 PM
Please respond
to
"ADSM: Dist
Stor Manager"
<ADSM-L AT VM DOT MAR
IST.EDU>
|------------|
| [ ] Secure |
| E-mail |
|------------|
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:steve_bennett AT ADMIN.STATE.AK DOT US]
Sent: Thursday, December 09, 2004 5:34 PM
To: ADSM-L AT VM.MARIST DOT EDU
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
==============================================================================
IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely for
the entity or individual to whom it is addressed. If you are not the intended
recipient, you should delete this message and are hereby notified that any
disclosure, copying, or distribution of this message is strictly prohibited.
Nothing in this email, including any attachment, is intended to be a legally
binding signature.
==============================================================================
