[Note: I am snipping out the information that is not relevant to the problem. I'm not trying to trick anybody ;)]
Executive summary: restore tvfb rst0l 10 will work on 5.1.2P1.
Below is a dialog with our F630 running 5.1.2P1 trying to read a tape written with 4.x. We were able to recover data from this tape using a filer running 4.3R4D2.
range> restore tvf rst0l RESTORE: Tape Block size should be 10240, not 64512. Fri Dec 18 13:00:12 EST [isp_main]: Tape block was shorter than byte count. Requested = 4096, Read = -50176 RESTORE: Could not initialize media. range> restore tvfb rst0l 64512 RESTORE: No buffers available.
Ok. This is actually a very simple problem. In every release before 5.1, dump's default tape record size (think 'b' option) was 10KB.
In 5.1, we changed this to 63KB. Most people _thought_ the default was always 63KB. It wasn't.
So, now, in 5.1, restore _also_ defaults to thinking the tape record size is 63KB.
We figured people would get bitten by this change, so we added the error message (which is obviously not effective) RESTORE: Tape Block size should be x, not y.
So, if you run your restore as: restore tvfb rst0l 10 you'll be happy with the results.
Now, how do I know the error message didn't work? 1) It prints out the tape record sizes in bytes, rather than 1KB blocks. That's fine, except that the command line wants the numbers in 1KB blocks. This will be changed for the next release. I apologize for this. Anyway, in your second test, restore is saying it can't grab 64512*1024 bytes. This isn't particularly surprising. Since most people don't use a 64MB tape record size, restore can't really hande that.
Again, this is our fault for printing out the wrong increment.
2) You seem to have chosen to use the number that restore said was a bad record size (i.e. 63KB). We need to make sure people try to use the 10KB.
We'll try to re-examine how to make that part of the message clearer as soon as we can.
In summary, dump/restore should be both _forward_ and _backward_ compatible, as well as ufsrestore compatible. If this ever changes, we will make sure everybody knows this.
Thanks for your patience, Stephen Manley FS Recovery Tenor