[Info-vax] Backup TK50 tapes

[Johnny Billquist]

On 2013-02-25 09:57, glen herrmannsfeldt wrote:
> Dennis Boone <drb at ihatespam.msu.edu> wrote:
>
> (snip)
>
>> You continue to fail to get it.  It's not about how "low-level" the
>> tool is.  The blocks aren't necessarily all the same size.  You may
>> not _know_ the size, even if they are.  The next guy who has to pick
>> up your image _probably_ doesn't know.  The size of the blocks matters
>> in many cases.  If you use dd, you THROW AWAY this information, and
>> save just a stream of bytes.  Don't use dd to image tapes.  Don't.
>> Eh eh eh, I see you thinking about doing it anyway.  STOP.  Use a
>> tool which saves this data.
>
> The unix read() and write() system calls don't throw away the length
> information, but the disk file systems do.
>
> Now, if you use ibs= and obs= then dd will reblock the data, even if
> you didn't want it to, but also if you did.
>
> But if you use bs= for tape to tape, dd does read for each block,
> and then write() for the block.

Yes. But what does dd use for the write? The actual size returned by the 
read, or the size in the bs argument?

Anyway, this discussion is pretty pointless. dd is just not the right 
tool, even if you can force it into service under some specific 
circumstances.

>> If you're going to use the image with a simulator, it probably wants
>> .tap format or similar anyway.  A .tap image preserves the block sizes.
>> There are plenty of tools for building such images.  Use one.
>
> Yes .tap or one of the other formats is often a good choice.

.tap, .tpc, whatever. Once you have any of them, it's trivial to convert 
to another.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol