Menu
▾
▴
#101 Tape decompression error while restoring <file removal list>
Using
Dump was created using -j5.
This is the output of the restore command:
# restore -i
Dump tape is compressed.
short compressed block: 32772 expected: 181076003
decompression error, block 33: length mismatch
Tape decompression error while restoring <file removal
list>
continue? [yn] y
short compressed block: 32772 expected: 229285325
decompression error, block 66: length mismatch
Segmentation fault (core dumped)
The interesting fact is that if I use:
# dd if=/dev/st0 | restore -i -f-
I can sucessfuly access and restore the data without
any problems.
Logged In: YES
user_id=5513
What does restore say if you also give '-dv' as options ?
Does specifying a blocksize (with '-b 32' or something else)
help ?
Stelian.
Logged In: YES
user_id=10857
I have tried a few different values of blocksize to no
avail. Once -b was not used for dump, I'm not sure it would
help with restore (all unit block setting were done with the
mt command).
I'll have to try with the -dv option. Btw, what does it mean
? I don't see it on the manpage or on the --help output. But
it will have to wait until monday anyway.
Logged In: YES
user_id=5513
dump uses a blocksize of 10 KB by default, whereas restore,
since it has to guess the blocksize, starts testing with
bigger values (64 KB IIRC), so specifying the real blocksize
to restore can help.
-d is debug and -v is verbose, and they are documented on
the restore man page, at least in the latest version.
Which makes me think, you seem to use an older version of
restore, so before going further, please also try with the
latest version of restore (0.4b36), in case the bug has
already been fixed.
Stelian.
Logged In: YES
user_id=10857
Been there, done that.
THe server was using an older version of dump (0.4b28).
After the problem, it was upgraded to 0.4b36. So restore is
on the latest version, although the tape was made with an
older version of dump.
Now, one interesting fact is that the blocksize was set
(using mt) to 1. Would restore still try to force blocksize
10 ? In case of dump, if you don't specify a new value with
-b, it will use the drive default. If restore is trying to
force blocksize 10, that could be the source of the problem.
(I was consulting the manpage on another machine, which
still uses 0.4b28)
Logged In: YES
user_id=5513
The tape blocksize sets the maximum amount of data you can
write on the tape in a single write (and the maximum amount
of data you can read in a single read too). By setting this
to 1 byte (mt takes bytes not kb !!!), you tell the tape
driver it can only write one byte at the time. Apart from
being excessively slow, it should not work at all...
The dump blocksize is the amount of data dump will write to
the tape (so it must be less or equal than the tape
blocksize). When restoring the tape, restore doesn't know
how big the blocksize is, so it has to try the biggest value
possible and look at how much data was effectively returned.
Typical blocksize usage is one of the following:
* set tape blocksize to 10240 bytes, use dump and restore
with the default blocksize
* set tape blocksize to 65536 bytes, pass -b 64 to dump,
restore should find the blocksize automatically
* set tape blocksize to 0 (this is called varlable blocksize
and is supported by some newer tape drives), and pass -b 64
(or whatever) to dump. Restore should also find the
blocksize automatically.
In your case, I suspect that the tape drive is indeed
reading 1 byte records, so restore cannot read it (because
restore has to read at least 1KB at one time), but dd issues
multiple reads, pack the data into full buffers and give it
to restore. In order to verify this, please run the dd
through strace (using for example:
strace -eread,write dd if=/dev/st0 > /dev/null
), we will get our answer in the output.
And don't forget the restore -dv run...
Stelian.
Logged In: YES
user_id=5513
No reply since my last post.
Should I consider the bug as fixed or do you have
additionnal problems to report ?
Stelian.
Logged In: YES
user_id=5513
Still no reply, closing.