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): How reproducible: Always 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 Additional info: 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.