Hi Arno,
I set "setdebug 1000" for storage-daemon. Is that what you mean?
Here is the full output of "stat sd=SL500-1". Actualy a backup is made on
virtual changer. The restore comes from volume 000239 at /dev/nst0. Last
restore runs over one hour.
*stat sd=SL500-1
Connecting to Storage daemon SL500-1 at dss-bacula:9103
dss-bacula-sd Version: 2.2.8 (26 January 2008) x86_64-pc-linux-gnu debian 4.0
Daemon started 03-Jul-08 11:36, 14 Jobs run since started.
Heap: heap=1,064,960 smbytes=706,834 max_bytes=805,292 bufs=205 max_bufs=243
Sizes: boffset_t=8 size_t=8 int32_t=4 int64_t=8
Running Jobs:
Writing: Full Backup job WLPS-o2rhmc0a_System JobId=8939 Volume="00113"
pool="Disk" device="FileStorage" (/stage0/drive0)
spooling=0 despooling=0 despool_wait=0
Files=49,691 Bytes=18,795,651,558 Bytes/sec=10,061,911
FDReadSeqNo=665,847 in_msg=537842 out_msg=5 fd=6
Reading: Full Restore job RestoreFiles_ReplaceAlways JobId=8951 Volume="000239"
pool="Disk" device="SL500-1-Drive-1" (/dev/nst0)
Writing: Full Restore job RestoreFiles_ReplaceAlways JobId=8951 Volume="000239"
pool="Disk" device="SL500-1-Drive-1" (/dev/nst0)
spooling=0 despooling=0 despool_wait=0
Files=0 Bytes=0 Bytes/sec=0
FDReadSeqNo=18 in_msg=17 out_msg=6 fd=10
====
Jobs waiting to reserve a drive:
====
Terminated Jobs:
JobId Level Files Bytes Status Finished Name
===================================================================
<terminated jobs>
====
Device status:
Autochanger "FileAutoChanger" with devices:
"FileStorage" (/stage0/drive0)
"FileStorage1" (/stage0/drive1)
Autochanger "SL500-1" with devices:
"SL500-1-Drive-1" (/dev/nst0)
"SL500-1-Drive-2" (/dev/nst1)
Device "FileStorage" (/stage0/drive0) is mounted with:
Volume: 00113
Pool: Disk
Media type: File
Slot 13 is loaded in drive 0.
Configured device capabilities:
EOF BSR BSF FSR FSF EOM !REM RACCESS AUTOMOUNT LABEL !ANONVOLS ALWAYSOPEN
Device state:
OPENED !TAPE LABEL !MALLOC APPEND !READ EOT !WEOT !EOF !NEXTVOL !SHORT !MOUNTED
num_writers=1 block=0
Device parameters:
Archive name: /stage0/drive0 Device name: FileStorage
File=3 block=3483699721
Min block=0 Max block=0
Total Bytes=16,368,601,610 Blocks=253,730 Bytes/block=64,511
Positioned at File=3 Block=3,483,699,721
Device "FileStorage1" (/stage0/drive1) is not open.
Drive 1 is not loaded.
Configured device capabilities:
EOF BSR BSF FSR FSF EOM !REM RACCESS AUTOMOUNT LABEL !ANONVOLS ALWAYSOPEN
Device state:
!OPENED !TAPE !LABEL !MALLOC !APPEND !READ !EOT !WEOT !EOF !NEXTVOL !SHORT
!MOUNTED
num_writers=0 block=0
Device parameters:
Archive name: /stage0/drive1 Device name: FileStorage1
File=0 block=0
Min block=0 Max block=0
---- this is the device with the restore job -----
Device "SL500-1-Drive-1" (/dev/nst0) is mounted with:
Volume: 000239
Pool: *unknown*
Media type: LTO-3
Slot 40 is loaded in drive 0.
Configured device capabilities:
EOF BSR BSF FSR FSF EOM REM !RACCESS AUTOMOUNT LABEL !ANONVOLS ALWAYSOPEN
Device state:
OPENED TAPE LABEL !MALLOC !APPEND READ !EOT !WEOT !EOF !NEXTVOL !SHORT !MOUNTED
num_writers=0 block=0
Device parameters:
Archive name: /dev/nst0 Device name: SL500-1-Drive-1
File=23 block=11690
Min block=0 Max block=0
Total Bytes Read=20,857,245,696 Blocks Read=323,308 Bytes/block=64,512
Positioned at File=23 Block=11,690
---------------------------------------------------------------
Device "SL500-1-Drive-2" (/dev/nst1) is not open.
Device is BLOCKED. User unmounted.
Drive 1 is not loaded.
Configured device capabilities:
EOF BSR BSF FSR FSF EOM REM !RACCESS AUTOMOUNT LABEL !ANONVOLS ALWAYSOPEN
Device state:
!OPENED TAPE !LABEL !MALLOC !APPEND !READ !EOT !WEOT !EOF !NEXTVOL !SHORT
!MOUNTED
num_writers=0 block=1
Device parameters:
Archive name: /dev/nst1 Device name: SL500-1-Drive-2
File=0 block=0
Min block=0 Max block=0
====
In Use Volume status:
000239 on device "SL500-1-Drive-1" (/dev/nst0)
Reader=1 writers=0 reserved=0 released=0
00113 on device "FileStorage" (/stage0/drive0)
Reader=0 writers=1 reserved=0 released=0
====
====
*
Now: fife minutes later, state of drive SL500-1-Drive-1
Device "SL500-1-Drive-1" (/dev/nst0) is mounted with:
Volume: 000239
Pool: *unknown*
Media type: LTO-3
Slot 40 is loaded in drive 0.
Configured device capabilities:
EOF BSR BSF FSR FSF EOM REM !RACCESS AUTOMOUNT LABEL !ANONVOLS ALWAYSOPEN
Device state:
OPENED TAPE LABEL !MALLOC !APPEND !READ !EOT !WEOT !EOF !NEXTVOL !SHORT !MOUNTED
num_writers=0 block=0
Device parameters:
Archive name: /dev/nst0 Device name: SL500-1-Drive-1
File=39 block=2171
Min block=0 Max block=0
Total Bytes Read=0 Blocks Read=0 Bytes/block=0
Positioned at File=39 Block=2,171
So you can see that bacula reads the entire volume to position on tape for
restore.
Greetings
Sebastian
> -----Ursprüngliche Nachricht-----
> Von: bacula-users-bounces AT lists.sourceforge DOT net
> [mailto:bacula-users-bounces AT lists.sourceforge DOT net] Im
> Auftrag von Arno Lehmann
> Gesendet: Donnerstag, 3. Juli 2008 13:02
> An: bacula-users AT lists.sourceforge DOT net
> Betreff: Re: [Bacula-users] restore runs infinite
>
>
> Hi,
>
> 03.07.2008 11:56, S.Lehmann8 AT DeutschePost DOT de wrote:
> > Hi,
> >
> > I had the same problem and made the tests you gave.
> > Result is, that the tape is very fast in tape positioning
> with mt, but with bacula, restore is very slow.
>
> Ok. That's not good, but it narrows down the possible reasons for the
> slowness.
>
> >
> > I have set some options, but there are already the defaults:
> >
> > Device {
> > Name = SL500-1-Drive-1
> > Drive Index = 0
> > Media Type = LTO-3
> > Archive Device = /dev/nst0
> > Automatic Mount = yes
> > Auto Changer = yes
> > Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
> > Label Media = yes
> > Random Access = No
> >
> > Hardware End Of Medium = Yes
> > Fast Forward Space File = Yes
> > Use MTIOCGET = Yes
> >
> > }
> >
> > At bconsole and the command stat sd you can see, that bacula not is
> > using Fast forward spaceing to jump to the file to restore.
>
> Bug report time, I guess :-)
>
> Which version of Bacula do you run?
>
> And can you send console output showing the problem (probably 'sta
> sd=...' with debug output enabled, right?)
>
> > The same problem persists with the file-devices!
>
> So it seems to be a general problem of the SD setting up its devices.
>
> If you don't report this on bugs.bacula.org, I'll do so if
> you send me
> more details :-)
>
> Arno
>
> > Greetings
> > Sebastian
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: bacula-users-bounces AT lists.sourceforge DOT net
> >> [mailto:bacula-users-bounces AT lists.sourceforge DOT net] Im
> >> Auftrag von Arno Lehmann
> >> Gesendet: Mittwoch, 2. Juli 2008 23:27
> >> An: bacula-users AT lists.sourceforge DOT net
> >> Betreff: Re: [Bacula-users] restore runs infinite
> >>
> >>
> >> 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
> >
> > <snip>
> >
> >> 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).
> >>
-------------------------------------------------------------------------
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
|
