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 tr
On Thursday 14 May 2020 17:30:53 Nathan Stratton Treadway wrote:
> On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> > Interesting, how can a "dirty" drive trigger this behavior?
> >
> > I'd expect failures all along and not after ~200 or 300 GB written.
> >
> > I don't see any
Glad you brought up this "feature" Nathan. I had heard it before
but not using tape, promptly forgot it.
Jon
On Thu, May 14, 2020 at 05:30:53PM -0400, Nathan Stratton Treadway wrote:
> On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> > Interesting, how can a "dirty" drive t
On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> Interesting, how can a "dirty" drive trigger this behavior?
>
> I'd expect failures all along and not after ~200 or 300 GB written.
>
> I don't see any interrupted writing or so (until that End Of Tape).
(We switched to disk-
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
On Thursday 14 May 2020 01:32:05 Jon LaBadie wrote:
> On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> > Now look at this run of
> >
> > "amtapetype -b 128k /dev/nst0"
> >
> > with another tape, FUJI instead of HP:
> >
> > define tapetype LTO3-fuji {
> > comment "Cre
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 cap
Am 14.05.20 um 07:32 schrieb Jon LaBadie:
> I wasn't sure what LEOM was. I assume it is "Logical End of Media".
Seems like, yes. I still haven't figured out how to set that, the
"device_property" line wasn't accepted by Amanda.
> Anyway I came across two references that said need for cleaning
>
