> > That is to say, the block size detected by ide-tape.c is 26kB, so if I
> > want to get all my data back I have to write to it in some multiple of
> > that block size.
>
> This is actually how it works on most if not all unixen (IRIX, HPUX...),
> and also on linux. Either you get a silent truncation or (most foten) you
> get an error.
>
> This is good, since e.g. dat drives will write partial blocks if not using
> the correct blocksize, and this can greatly reduce the capacity of the
> tape.
But isn't ide-tape.c supposed to take care of buffering the blocks and
using the correct blocksize?
What I really want to know is, why do I have to specify a blocksize now,
implicitly? We have a lot of machines here, and are fortunate enough to
have other machines with different kernels and the same drives, and other
machines with the same kernel and different drives. This machine is the
only one to require a blocksize specified implicitly, and then only after
upgrading the kernel.
Major changes occured in the ide-tape.c driver around 2.2.11, I believe,
and a few here and there in between. The BRU people assured me that this
is a kernel bug that can be fixed simply by using 2.2.7, but I can't
simply compile that version of the driver because the relevant ide calls
have changed significantly since then, and I really don't know enough
about it to be mucking around with kernel-level tape driver code.
> Backups programs simply have to write using the correct blocksize.
I agree; and I'm sure they do. But I never had to specify a 'tar -b 26',
a 'dd bs=26k', or a 'bru -b 26624' until now to have my data written
correctly. Do you have to do this in your backup scripts, and do they get
broken by a new tape drive or kernel? Would you expect to have to do a
'bru -b 512 -cvf /dev/fd0' to have that succeed, or is that something the
driver should handle?
No, really, I'm curious. I'm pretty sure this is a kernel driver issue,
but if I really am wrong on this one, and everyone really does have to
specify these options now, please tell me, and tell me why, and then I'll
shut up about it, and apologize. :)
> --
> -----==- |
> ----==-- _ |
> ---==---(_)__ __ ____ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / pcg@opengroup.org |e|
> -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
>
Thanks for the information,
Peter Baylies
American Data Technology
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:19 EST