Red Hat Bugzilla – Bug 67157
Restore VERY slow compared to dump speeds
Last modified: 2007-04-18 12:43:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0; Q312461)
Description of problem:
A volume takes 1 1/2 hourse to dump to a 40GB DLT device. A restore of about
ten files (using restore if <device>) from that volume is still running 5 hours
later. I know the files are on tape because I have done 'ls' in interactive
mode (and am fully fa,iliar with dump/restore on several UNIX platforms.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.mt -f /dev/nst0 fsf 2
2.restore if /dev/st0
3.restore > cd <directory which contains files>
4.restore > add *
5.restore > extract
You have not read any tapes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
Actual Results: Still wating five hours later ...
Expected Results: files recovered after a maximum of 1 1/2 hours
dump version dump-0.4b25-1.72.0
The tape device is a scsi wide differential Quantum DLT4000 which is recognised
by the SCSI Controller at bootup, and a test restore from this device has
worked (dumped from a small volume)
Arjan, Stephen, Doug: Any suggestions?
For the most part, this is limited by tape read speeds. I've seen two things in
the past result in *very* slow tape read speeds. 1) Bad tapes that are marginal
and result in lots of error recovery actions in order to actually read the data.
You can usually tell if this is the case because the tape drive will stop
streaming, rewind a bit, then start again and it will do this little backup and
retry thing a *lot*. It kills performance and there isn't anything linux can do
about it. 2) Writing a tape in a block mode that the tape drive can't read back
very well. For example, setting the block size on st0 to 0 then writing to tape
and then restoring from that tape may work significantly slower than setting the
block size on st0 to 32k and then writing out the backup and then restoring. In
this case, the only thing to do is to do a little experimentation with various
tape drive settings like block size and compression and perform a backup with
each setting and then see how speedily the restore can be done with each
setting. Once you find a setting that performs well, stick with it as your default.
If neither of these solves your problem, then reopen the bug report. However,
until there is something else to go on, this doesn't sound like a bug to me, it
sounds like hardware issues.