On Thu, May 14, 2020 at 09:14:17AM +0200, Stefan G. Weichinger wrote: > Am 14.05.20 um 07:59 schrieb Jens Berg: > > There was a discussion back in 2014 with subject "Backups to tape > > consistently under 60% tape capacity". I haven't read the whole lengthy > > thread but one participant mentioned that in his case a bad cleaning > > tape was found to be responsible for the capacity loss. Others reported > > that they had trouble with the compression settings. My gut feeling > > tells me that this is not the problem here but maybe your impression is > > a different one or you get a new idea if you read through the postings. > > Thanks for the pointer. > > Interesting, how can a "dirty" drive trigger this behavior? >
Because somewhere along the line, some piece of the software does not distinguish an error return as distinct from an EOF or EOM. By the time it gets to the human, it is an EOF even if it was an error. For example, some writing functions return only success/failure. Is that failure the end of tape or some other error? Does the code assume one and not investigate further? If the code does investigate further, is there a way to tell the upstream code success/EOF/error or just two statuses? > But it's worth a try, the customer for sure hasn't used the cleaning > tape for years. Sounds like a plan. Maybe two runs? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
