Subject: Re: amanda
To: Greg Troxel <firstname.lastname@example.org>
From: Aaron J. Grier <email@example.com>
Date: 12/10/2006 19:36:18
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" <firstname.lastname@example.org> 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
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." | email@example.com
"silly brewer, saaz are for pils!" -- virt