On Fri, 26 Apr 2002 at 2:06am, [EMAIL PROTECTED] wrote > Since the c1t1d0s0 partition is greater than the standard capacity of the tape, > unless I lie to amanda about the tape capacity--call it 2GB instead of 1GB for > instance--it will never back up this partition because there will never > be a tape onto which it will fit. I have tried it, and that's the result I got.
But "lying" to amanda about tapelength is *exactly* how you use hardware compression. > Hence the trick with software compression for one partition only--this fools > the planner into using half the actual size, which it reckons it can get onto > a tape. In practice the reported compression is 0.57, which is not bad at all. But that blows up when you put it on tape, because you're trying to compress already compressed data. So the compressed size amanda reports is *not* how much space that partition takes up on tape. > I don't want to call the tape capacity 2GB though, because amanda will attempt > to get everything onto one tape, and I happen to know this will overshoot > by a a little bit. Thus amanda wastes an enormous amount of time trying to fit > c1t1d0s0 onto tape one. Software compression on a 75Mhz Sparc 5 is _s_l_o_w_ So tell amanda a tapelength just under your total size. Amanda will do the right thing. > What I'm going to try next is rerun tapetype with hardware compression on, and > use that with amanda compression off. If I put the big partition first in the > disk list, perhaps amanda will waste less time... Don't Do That. tapetype writes random data, which doesn't compress at all. Thus the results you posted in your next mail. > I see that configuring a factor for hardware compression is still > for a future enhancement, so unless someone has a better idea the solution > seems to be along these lines. I will simply have to pretend that the > compressed capacity is the real capacity, and hope for the best. But there is no one factor for hardware compression. It depends *highly* upon the type of data, and thus will vary from filesystem to filesystem. It's not something you can compute once and forget about. > This inability to span a dump across tapes is really, really annoying...it > should not be necessary to experiment with these hacks. Of course I can see > how this came about and why it might be good. The feature is planned, and being worked on. Code is welcome. > On a related subject: some of my client systems are very fast and I'd prefer > to compress the data there before sending to the server. Is there anyway to > specify the non-compression device for these dumps, or will amanda accept just > one tapedev for everything? You get one tapedev per setup. You can always have multiple setups, though. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
