<tt><font size=2>Hi,</font></tt>
<br><tt><font size=2><br>
> the very first challenge is to find what data has changed. the way
<br>
> TSM does this is by crawling trough your filesystem, looking at <br>
> mtime on each file to find out which file has changed. think about
a<br>
> ls -Rl on your filesystem root. this </font></tt>
<br><tt><font size=2>> <br>
> The mmbackup mmapplypolicy phase is not a problem. It's going to <br>
> take as long as it's going to take. We're using 5 RAID1 SAS SSD <br>
> NSD's for metadata and it takes ~1 hour to do the traversal through
<br>
> 157 million files.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br>
<br><tt><font size=2>that sounds too long, if you want i could take a look
at your gpfs config and make suggestions on how to further improve this.
</font></tt>
<br><tt><font size=2>if you want me to do that please send me a email with
the output of mmlscluster,mmlsconfig,mmlsnsd and mmlsfs all to oehmes@us.ibm.com
</font></tt>
<br>
<br><tt><font size=2>> <br>
> the 2nd challenge is if you have to backup a very large number <br>
> (millions) of very small (<32k) files. <br>
> the main issue here is that for each file TSM issues a random i/o
to<br>
> GPFS, one at a time, so your throughput directly correlates with <br>
> size of the files and latency for a single file read operation. if
<br>
> you are not on 3.5 TL3 and/or your files don't fit into the inode
<br>
> its actually even 2 random i/os that are issued as you need to read
<br>
> the metadata followed by the data block for the file. <br>
> in this scenario you can only do 2 things : </font></tt>
<br><tt><font size=2>> <br>
> The problem here is why is a single rsync or tar | tar process <br>
> orders of magnitude faster than a single tsm client at pulling data
<br>
> off of GPFS into the same backup system's disk (e.g. disk pool)? <br>
> It's not a problem with GPFS, it's a problem with TSM itself. </font></tt>
<br><tt><font size=2>> We tried various things, e.g. :</font></tt>
<br><tt><font size=2>> <br>
> 1) changed commmethod to sharedmem</font></tt>
<br><tt><font size=2>> 2) increase txnbytelimit to 10G</font></tt>
<br><tt><font size=2>> 3) increased movesizethresh to the same as txnbytelimit
(10G)</font></tt>
<br><tt><font size=2>> 4) increase diskbufsize to 1023kb</font></tt>
<br><tt><font size=2>> 5) increased txngroupmax to 65000</font></tt>
<br><tt><font size=2>> 6) increased movesizethresh to 10240</font></tt>
<br><tt><font size=2>> <br>
> the next problem is that one would expect backups to tape to do <br>
> straight sequential I/O to tape, in the case of putting the files
to<br>
> the disk pool before moving them to tape, it did the same random I/O<br>
> to tape even with 8GB disk pool chunks. We haven't tried the file
<br>
> pool option yet, but we've been told that it'll do the same thing.
</font></tt>
<br>
<br><tt><font size=2>i assume you refer to using raw disks behind TSM ?
i never used them, in fact the fastest TSM Storage you can build for TSM
is to use a GPFS filesystem and put files into the filesystem and create
a pool with sequential file volumes for TSM. if you match the gpfs blocksize
with the raid blocksize you get very high throughputs to the TSM pool,
i have customers who see >600 MB/sec backup throughput to a single TSM
Server in production. </font></tt>
<br><tt><font size=2>> If I'm tar'ing or dd'ing large files to tape
that's the most <br>
> efficient, why doesn't TSM do something similar?</font></tt>
<br>
<br><tt><font size=2>i can't tell you much about the tape part of TSM but
i can help you speed up the ingest into a TSM Server leveraging a Filesystem
pool if you want.</font></tt>
<br>
<br><tt><font size=2>> <br>
> <br>
> 1. parallelism - mmbackup again starts multiple processes in <br>
> parallel to speed up this phase of the backup </font></tt>
<br><tt><font size=2>> <br>
> ..use multiple clients. This would help, but again I'm trying to get<br>
> a single tsm client to be on par with a single "cp" process.</font></tt>
<br>
<br><tt><font size=2>cp uses buffered write operation and therefore will
not sync the data to the disk, which is why its faster. TSM guarantees
each write operation to to be committed to stable storage before it ever
returns to the client, this is most likely the difference you see. </font></tt>
<br>
<br><tt><font size=2>don't get me wrong, i don't try to defend the way
TSM works, i just know that there are several ways to make it fast and
i am happy to help with that :-)</font></tt>
<br>
<br><tt><font size=2>if you need a single TSM client to run faster, then
option 2 (helper process) would fix that. if you want to try something
out send me a email and i can help you with that. </font></tt>
<br>
<br><tt><font size=2>> <br>
> Thanks,</font></tt>
<br><tt><font size=2>> Sabuj_______________________________________________<br>
> gpfsug-discuss mailing list<br>
> gpfsug-discuss at gpfsug.org<br>
> </font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br>
</font></tt>