|
Re: *Slow* amrestore
2004-03-11 14:54:32
Hmm. Check also "mt status" to make sure the drive thinks that the
blocksize is "0" if not change it with "mt blksize". The files will be
perfectly fine with bs=16M. gzip and/or tar will probably give a warning
bitching about the nulls at the end, but it won't have any effect on the
restore, the files will still be intact.
In some desparate cases in the past, where some mung brain had data on
Sony Video 8 tapes (!) I ended up mucking around with "mt blksize" and
just using "cat" to try to grab the stuff off the tape without any
blocking, crazy as that sounds, but that was also on SGI IRIX with
Exabyte 820 "Eagle" drives. It was a pain, and there were loads of
errors, but I got most of the data off the tapes.
--jonathan
Joshua Baker-LePain wrote:
On Thu, 11 Mar 2004 at 2:21pm, Jonathan Dill wrote
I would try "amrestore -c" to just dump the image off the tape, and then
do the uncompress and extraction separately, but you will need enough
disk space to do it. Worst case, you could try "amrestore -r" and use
"dd bs=32k skip=1 if=dump-file" to skip over the header, and then pipe
that to the uncompress and extract processes.
The current slow-running process is 'amrestore -r'. I'm guessing it's
forcing the block size that's the culprit here -- the amrestore man page
isn't quite clear, but it seems to say that if you don't specify -b,
it'll default to 32k. I tried just 'dd if=/dev/nst1 of=img.raw' but it
said "dd: reading `/dev/nst1': Cannot allocate memory". tapeinfo says
this about blocksizes for the drive:
MinBlock:2
MaxBlock:16777215
Maybe I should try dd with bs=16M? But will that pad the output file with
an unacceptable-to-tar chunk at the end since the tapefile is unlikely to
be an exact multiple of 16M?
Thanks.
|
|
|
