Tim wrote: "(If you don't pre-allocate the volumes they continually grow
resulting in a lot of file system fragments)."
Certainly true.
If one could change default fragment size for file expansion,
which seems to be set to only few kBytes on NTFS,
to maybe hundreds of MBytes, this could help much.
I could do it 25 years ago, as file system setting
on 2 of 3 available loadable file-systems on 16-bit PDP-11, which was
machine runningf RSX (multi-user multi-tasking OS requiring almost 1/2 MB RAM)
Is there a way to change this behaviour under current,
newer than NewTechnology operating systems?
AFAIK, programmers may change this value on opened NTFS file basis,
maybe is somebody from IBM/Tivoli hearing.
I played with those values on PDP and it did have
huge impact on operational speed.
best regards
Juraj Salak, Austria
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
|
