> On Jul 22, 2025, at 10:12 AM, Greg Troxel <g...@lexort.com> wrote:
>
> vom513 <vom...@gmail.com> writes:
>
>> I have been messing around with some tape drives on NetBSD. The one in
>> question now is a bit older (Sun branded HP DDS4) - but it was new old stock
>> right out of the factory box. It’s been cleaned as well.
>>
>> So under NetBSD - I can write to tape seemingly just fine. Reading back
>> (extracting) however goes south immediately. Using the stock tar I get
>> “damaged archive” and it gives up soon after starting the operation.
>>
>> I saw some old message of someone on FreeBSD having (what I thought
>> was) a similar issue to me - and they used GNU tar to work around
>> this. I built gtar from pkgsrc, but it fails in basically the same
>> way (albeit with a different “skipping to next header” type error).
>>
>> I put this same tape drive on an x86 PC running Debian Linux 12 and I get no
>> errors at all. It behaves exactly as I would expect.
>>
>> Is there something in NetBSD that precludes me from using this hardware
>> properly ?
>
Thanks for the reply. I’m far from an expert on the buffering tweaks to get
the source/disk speed better matched to the tape speed but I am somewhat aware.
And just to test this initially, I’m not setting a blocking factor in tar.
I typically set/confirm with mt that the device is set to 0/variable block and
then search around for a recommended blocking factor for the hardware in
question. For example - my Exabyte Mammoth 8mm (not this device) supposedly is
best with 240k (tar -b 480)
> You left out of your message:
>
> the dmesg lines from the tape
>
[ 1.051118] ahc0 at pci3 dev 6 function 0: Adaptec 2940 Ultra SCSI adapter
[ 1.051118] ahc0: interrupting at ioapic0 pin 21
[ 1.051118] ahc0: aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
[ 1.051118] scsibus0 at ahc0: 16 targets, 8 luns per target
...
[ 6.082604] st0 at scsibus0 target 4 lun 0: <HP, C5683A, C005> tape
removable
[ 6.082604] st0: density code 140, variable blocks, write-enabled
[ 6.092600] st0: sync (100.00ns offset 8), 16-bit (20.000MB/s) transfers
> the command you ran to write
tar -cpvf /dev/st0 /usr/pkg/
>
> the command you ran to read, and the error output
tar -xvpf /dev/st0
So this output above is from a modernish amd64 PC. I just installed NetBSD
10.1 on an extra drive and used the same tape drive and SCSI cable. Still get
“damaged archive” errors on this. (Using stock tar not gtar here out of
laziness for now).
The fact that Linux seems to write and read with no errors with no fancy mt/tar
settings still makes me think there is something NetBSD specific at play here.
Thanks.
