vom513 <vom...@gmail.com> writes: > And just to test this initially, I’m not setting a blocking factor in tar.
That's probably not a good plan. > 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) an interesting value. not 256k! > [ 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 That looks pretty normal. (I used to have a DDS 2 drive.) >> 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 Which does not include error output and does not say if anything is printed first. > 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. I would suggest: reading the tar man page and setting a block size of 128 kb for writing and reading doing tar to a file, and then writing it with dd and explicit block size then rewind and read with that block size running under ktrace, so you can see what syscalls are made and what the results are but really I think you need to do simpler tests with dd to understand more.
