On Fri, 26 Apr 2002 at 4:01am, [EMAIL PROTECTED] wrote > > 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.
As always, this depends a *lot* on your users. On our RAID (which I backup via amanda and tar), I have all sorts of data. A big chunk of it is raw ultrasound data (doesn't compress for sh$t), another big chunk is code (compresses quite well, thank you), and the rest is the usual hodge-podge. What a particular disklist entry contains *can* vary widely day to day. As a result, even though I'm using hardware compression, I've pretty much given up on getting any more than native capacity on the tapes (after hitting EOT quite a bit). > 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. But can one tape be written to in both compressed and uncompressed modes and be understood when the tape drive tries to read it? It was my understanding that the tape header tells the drive whether or not to use compression, and that's a per tape (not per file) value. But, of course, ICBW... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
