RE: port-amd64/53890: st(4) driver for tapes not working o variable block size

["G J van der Grinten" <pa0gri%amsat.org@localhost>]

The following reply was made to PR port-amd64/53890; it has been noted by GNATS.

From: "G J van der Grinten" <pa0gri%amsat.org@localhost>
To: <gnats-bugs%NetBSD.org@localhost>,
	<port-amd64-maintainer%netbsd.org@localhost>,
	<gnats-admin%netbsd.org@localhost>,
	<netbsd-bugs%netbsd.org@localhost>
Cc: 
Subject: RE: port-amd64/53890: st(4) driver for tapes not working o variable block size
Date: Sat, 19 Jan 2019 19:03:13 +0100

 Hello Michael,
 
 That is why TAR and family work as they use 20 *DEV_BSIZE blocks.
 
 The check could thus be skipped for real reel tape devices.
 But indeed if tape i/o is a single operation and does not conflict with other
 operations.
 
 Thanks for the update.
 
 Regards, Gerard
 
 -----Original Message-----
 From: Michael van Elst [mailto:mlelstv%serpens.de@localhost] 
 Sent: Saturday, January 19, 2019 5:30 PM
 To: port-amd64-maintainer%netbsd.org@localhost; gnats-admin%netbsd.org@localhost;
 netbsd-bugs%netbsd.org@localhost; pa0gri%amsat.org@localhost
 Subject: Re: port-amd64/53890: st(4) driver for tapes not working o variable
 block size
 
 The following reply was made to PR port-amd64/53890; it has been noted by GNATS.
 
 From: mlelstv%serpens.de@localhost (Michael van Elst)
 To: gnats-bugs%netbsd.org@localhost
 Cc: 
 Subject: Re: port-amd64/53890: st(4) driver for tapes not working o variable
 block size
 Date: Sat, 19 Jan 2019 16:27:38 -0000 (UTC)
 
  mlelstv%serpens.de@localhost (Michael van Elst) writes:
  
  > Looks like this is not the tape driver itself. The kernel physio() routine
  > does a sanity check on the I/O byte offset to be a multiple of DEV_BSIZE
  > (== 512 bytes) and returns EINVAL if that's false. That's why the
  > second read or write fails (the first starts at offset 0).
  
  The sanity check is done because physio() may issue concurrent
  partial I/O requests and keeps track of the individual parts
  by their block number. The block number addresses DEV_BSIZE
  blocks, so the algorithm only works for multiples of 512 bytes.
  
  A simple solution would be to not track absolute but relative
  offsets. This would still fail when physio has to handle I/O of
  multiple memory blocks (the second might be unaligned again),
  but the tape driver only starts I/O for a single block.
  
  -- 
  -- 
                                  Michael van Elst
  Internet: mlelstv%serpens.de@localhost
                                  "A potential Snark may lurk in every tree."