> But "lying" to amanda about tapelength is *exactly* how you use hardware > compression.
yes, I've figured that out now. > > 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. Hence the weird results I got. > > So tell amanda a tapelength just under your total size. Amanda will do > the right thing. Is doing so now, I think. > > Don't Do That. tapetype writes random data, which doesn't compress at > all. Thus the results you posted in your next mail. And Jon has noted the difficulty of obtaining a 'typical' compression rate. Interestingly, most of the time over the years, except with seismic data and graphics, about 1.6 seems to be good for me. I suspect tape compression is optimised for exactly the sort of systems I've usually dealt with: databases and gp multiuser. Naturally I've seen better and worse, but it's always been a good starting point for estimation. > > > 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. I have to disagree. Unless the usage pattern changes radically, you probably can once you have a feel for the numbers. > > > 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. If I were a better programmer, perhaps it might be... as things stand tho :-) > > > On a related subject: some of my client systems are very fast and I'd prefe > r > > 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 j > ust > > one tapedev for everything? > > You get one tapedev per setup. You can always have multiple setups, > though. It would seem more sensible to me to either allow multiple tapedevs (move tapedev to dumptype) or move tapedev to disklist, so devices can be grouped with tasks within the one config. Most shops have a collection of units dating back years and would prefer to manage them by one interface and one database. This is how the commercial products work, after all, and there is a reason. Chuck
