redirected to tech-pkg since this seems to be more relevant there...

On Sat, Dec 09, 2006 at 09:43:47AM -0500, Greg Troxel wrote:
> "Aaron J. Grier" <agrier@poofygoof.com> writes:
> > /netbsd: st0: 65536-byte tape record too big for 32768-byte user buffer 
> 
> What did amtapetype print?

amtapetype: /dev/nrst0: reading label: Input/output error

> > I need to grovel the source code for amanda; I suspect that if
> > amtapetype did the proper block size ioctl() before reading a tape
> > label, things would work correctly with block sizes other than 32k.
> 
> amtapetype reads the tape to see if there's an amanda label, in order
> to avoid writing on an in-use tape.
> 
> From your mail, it sounds like the tape you had in the drive had data
> on it with 64k blocksize.  Does this seem likely?

larger, actually.  I had dd'd some 512k records to tape earlier.  I
think 64k is just what the scsi driver layer happens to return.  maybe
that changes depending on the hardware, although ISTR a hardcoded I/O
limit of 64k per operation somewhere, or maybe it's a limitation of the
ahc driver I'm using.

> If so, I'm not sure setblk 32768 would help.   From skimming the
> driver, it looks like it will default to variable-length blocks.

you did see my example:  ;)

> > I was able to work around it by:
> >
> > $ mt -f /dev/nrst0 setblk 32768
> > $ dd if=/dev/zero of=/dev/rst0 bs=32k count=10
> > $ dd if=/dev/rst0 of=/dev/null bs=32k count=10
> >
> > and then amtapetype would work.
>
> I doubt it, but it may be that reads of blocks bigger than the user's
> buffer are expected to work on other operating systems, returning the
> first 32k, rather than failing.  It sounds like the read failed; the
> driver sets EIO.  See src/sys/dev/scsipi/st.c line 2236.

that's exactly what's happening, and is a caveat mentioned in the
mtio(4) manpage when using the raw device: "user programs must implement
specific magnetic tape handling routines, which puts the onus of
correctness on the application programmer."

I have no idea what other OSes do if the tape block is larger than the
user buffer.  if they are internally splitting reads in the kernel, then
that's hardly a raw interface.  it seems equally as bad to drop the rest
of the block.  the safest most conservative choice seems to be what
NetBSD is doing, and complaining about it.

> So, amtapetype should have had a failed read, and decided that it
> couldn't tell if the tape was an amanda tape, and tell you that you
> have to use -o to overwrite the tape.

amtapetype -o still attempts to read a label.  (it seems like it
shouldn't, if it's going to overwrite one anyway.)

> So I'm not sure what the right thing to do is.  Perhaps amtapetype
> should have a way to query the tape blocksize, or to use a really big
> blocksize since short reads are ok.

the blocksize defaults to 32kB.  adding

CONFIGURE_ARGS+=        --with-maxtapeblocksize=64

to sysutils/amanda-common/Makefile.common appears to make amtapetype
happy.  I've filed PR pkg/35231 as a result.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
              "silly brewer, saaz are for pils!"  --  virt