Am 13.05.20 um 18:17 schrieb Stefan G. Weichinger:
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
> comment "Created by amtapetype; compression disabled"
> length 284180096 kbytes
> filemark 20803 kbytes
> speed 38376 kps
> blocksize 128 kbytes
> }
>
> ~290 GB ... faster, and large filemarks.
>
> Maybe that drive is somehow failing .. ?
Thanks all for you replies.
I let them re-clean today and we use the ~290GB tapetype for now and
look if things work.
I am gonna restore as well just to check if there are hidden write
errors (doesn't look like that to me so far ...)
Spent many hours with this over the last few days. Maybe we should
consider moving over to vtapes as well (although this brings up other
issues).
ah btw:
with a plain dd the tape was also over at around 200 GB
I suspect a wrong setting somewhere but my googling for stinit settings
doesn't give me good infos.
Back in 2019 I find reports of exactly this setup writing:
323403M
323642M
354610M
345766M
343395M
343781M
and around new year it started complaining
Maybe another few cleaning runs help.
