Anybody who's using FILE devclasses to accept backups willing to discuss their config, how they got there, and what they like and dislike?
I'm working out how to use FILE devclasses effectively, and am a little exasperated. I started off with fairly small maxcap (2G) , and a large maxscratch. My migration was hammered because the migration process switched source volume without particularly considering what other FILE volumes might be emptied onto the tape it had mounted. Reading the docs, this seems to be a core architectural choice, and I can understand how they got there from the serial media way of treating volumes. But it hurts a lot, in this environment. My biggest bottleneck is tape drive hours: Every tape change looks to me like some 11G of data not moved (3min x 60M/min) ; Even if I've got only 500 of my 1100-mumble nodes affected in a day's work, even if it's just one additional mount per node, that's 25 tape-drive-hours eaten up in unneccesary mounts. And all of those estimate numbers are conservative. Ick. Ick ickety ick. At this moment I've made fairly large volumes (50G) sized to be larger than the second standard deviation of a single node's nightly backup, and set node collocation on the FILE devclass, plus a maxscratch significantly larger than the node count. I was anticipating this would leave me with homogenous volumes. D'oh, forgot about resourceutilization. Next I intend to set maxscratch as higher than nodecount*5. So, I'm going to define a stgpool with maxscratch 750, 50G volumes: titularly assigning 37.5 TB of data. Hah. Using this strategy makes a hash of any kind of quota or cap on a given TSM server's use of a shared disk resource. Of course, it's still possible that if I have 4 FILE volumes occupied with only FOONODE data, I'll still do them out of order, and have to mount FOONODE's tape volume four times. In this case, I'm not winning anything by going from nodecount to nodecount*5. It appears, from the docs, that this is what will happen. But I'm going to test and make sure. It seems that this would be a non-issue if the migration process were sensible to the fact that it's extremely low cost to remount FILE volumes. So, what am I doing wrong? Is there a big red button marked "Don't Be An Idiot" which I'm failing to push? If I can't fix these issues, I will have to ditch the FILE devclass notion; I can't justify spending an additional $20-30K on drives... MMmm. Maybe I should have a _smaller_ disk stgpool migrating into the FILE devclass, .... Eeek. Double the I/Os in a night? I like to over-engineer, but that's a little much even for me. - Allen S. Rout
