Richard Sims wrote: > On Mar 13, 2006, at 12:24 PM, Remco Post wrote: > > You can refer to the description of transaction processing in the > Admin Guide manual, and the original description of Small File > Aggregation in the ADSMv3 Technical Guide, to appreciate the > mechanism and its controls. The combination of TXNGroupmax and > TXNBytelimit govern the transaction and Aggregate size. In modern TSM > servers, TXNGroupmax may be defined individually for each node. >
thanks, will look into that, again. I wasn't really impressed by the clarity of the chapters when I read them, just yesterday ;-) > Aggregation distances logical file size from the MAXSize value: you > have coarse, rather than fine control. You could conceptually reduce > your client TXNBytelimit, but that then applies to all transmissions, > and could impair performance. (Note the huge jump in the default > TXNBytelimit value in TSM 5.3, for performance.) MAXSize is thus a > reasonableness value for storage pool apportionment rather than a way > of having only files in a certain size range stored in a given > storage pool. > ok, let's make this clear beyond any doubt: I don't care either way, I like aggregates and I do appriciate their benefits, but I do want to know every detail about how aggregation and the maxsize parameter interact. I don't want to reduce tnxbytelimit or tnxgroupmax, large transactions are a must to keep performance up. > In considering all this, appreciate that TSM is an Enterprise > product, intended to deal with large volumes of data, en masse. Its > controls are by classes of data rather than by specific object > attributes, such as size. The objective is overall throughput speed, > to keep today's high volume of data moving. Keeping small files > separate from large files is not a product objective, where relative > age is a more common differentiator for restorals, and thus migration. > :-) Do realize that diskpool's currently will not be able to handle the database backups of over 64GB, since the single object doesn't fit in a diskpool volume (due to restrictions on the size of diskpool volumes). I would of course love to have my active files (save for the huge ones) on-line and inactive versions off-line. Unfortunately, that is in the future. Overall throughput is nice, but being able te restore small files in seconds rather than minutes is a big seller. Having over 70% of all single file resotres, inrespective of file-age, not put any load on tape-drives could greatly increase customer satisfaction as well as reduce the load on my tape-drives. I currently have only 8 9940B drives and 4 9840C drives for TSM and investing 20-40 k$ in disk rather than in tape could be justified. I do need correct info on these details to be able to both justify the investment and predict it's impact. (and market it to my customers and convince my boss). With these file-sizes, for files larger than the maxsize I'm currently thinking of the tape mount-dismount times are still substantial compared to the data transfer time. But not having a tape-drive busy for 2-3 minutes for a single 1k (or even 10M) restore, which do happen a lot more often than the 90Gig restores, would be worth cosiddering, if only I could all the correct details about TSM's workings ;-) About TSM being enterprise: tell that to those who don't store 140000000+ files or 80TB (time 2 for the copy stgpool) in a single TSM server ;-) I do appriciate TSM, we do have a p630 move over 2TB per 12 hours without any problems. We're just looking for ways of increasing customer experience without any disproportionate investment and thus impact on the cost of backups. > Richard Sims So now for the question at hand, how do aggregation and the maxsize parameter interact? Both during B/A and migration/reclamation? (yes I didn't notice a direct answer to my question in your posting ;-)) -- Met vriendelijke groeten, Remco Post SARA - Reken- en Netwerkdiensten http://www.sara.nl High Performance Computing Tel. +31 20 592 3000 Fax. +31 20 668 3167 PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16 B3F6 048A 02BF DC93 94EC "I really didn't foresee the Internet. But then, neither did the computer industry. Not that that tells us very much of course - the computer industry didn't even foresee that the century was going to end." -- Douglas Adams
