Hello,
02.07.2008 14:10, Udo Lembke wrote:
> Hi,
> below is our sd.conf.
> The baculahost is an amd64 Gentoo-Linux (Gentoo Base System release
> 1.12.9 - 2.6.20-gentoo-r8).
> In the /usr/include/gentoo-multilib/amd64/sys/mtio.h aren't specific
> values for LTO-2 (the newest is DDS).
That's ok, I believe - LTO is pretty much standard SCSI tape from the
st driver's point of view.
> mt -f /dev/nst0 status
> SCSI 2 tape drive:
> File number=314, block number=0, partition=0.
> Tape block size 0 bytes. Density code 0x42 (LTO-2).
> Soft error count since last status=0
> General status bits on (81010000):
> EOF ONLINE IM_REP_EN
>
> Versions:
> mt-st 0.9b
> mtx 1.2.18
>
> Do you need any further information?
>
...
> Device {
> Name = Drive-1
> Drive Index = 0
> Media Type = LTO-2
> Archive Device = /dev/nst0
> AutomaticMount = yes;
> AlwaysOpen = yes;
> RemovableMedia = yes;
> RandomAccess = no;
> AutoChanger = yes;
> Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
> }
Good... this is like a "default" setting.
Unfortunately, the defaults should allow Bacula to quickly position
the tape to the location needed for a restore.
(Fast forward space file, Backward space file, Forward space record,
forward space file, Block positioning are the directives I was looking
for... these all need to be set to yes for good tape positioning
performance).
Now I can only recommend to do some tests (without the SD running, or
at least with unmounted tapes!):
- Load a full and *write-protected* tape
- time mt -f /dev/nst0 rew (should be instantaneous with a freshly
loaded tape)
- time mt -f ... eom (might take a while - positioning to the end of
the tape) Keep the time this takes in mind
- mt -f ... status Note the file number mt reports. It should be
pretty high.
- mt -f ... rew again
- mt -f fsfm <number a bit below the one you found out above> This is
the time you can expect to need to wait after initiating a restore,
before the tape is positioned to the right place.
- unload the tape, remove the write protection, load the tape into the
autochanger and enable Bacula for this tape drive again (mounting or
starting the SD).
Normally, tape positioning should not take more than a few minutes for
LTO.
If it does, the tape drive is not doing fast seeks but the driver
reads actual data until it reaches the specified position. If that
happens, and is not due to the SD configuration, you'll have to
examine how the st driver determines its mode of operation - I never
encountered such a case...
Hope this helps you examining this a bit.
And, of course, it *could* be that, actually, Bacula had to do some
work internally (though your output didn't look like that).
Arno
--
Arno Lehmann
IT-Service Lehmann
www.its-lehmann.de
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
