When restoring (a single file) from a tape that has multiple jobs
written on, the SD does not skip the irrelevant jobs until it gets
to the one that contains the file; instead it reads every single
block of every job(!) until it reaches the relevant one.
First I thought this comes due to the stupid tapedriver
(FreeBSD 5.5), but this happens only on restore; on backup
it can at least do repeated "fsf 1".
So I switched on debugging. The job is the 3rd one on the tape.
In the catalog I see:
table "job" : volsessid=144
table "file" : fileindex=1
table "jobmedia: : firstindex=1
lastindex=7
startfile=0
endfile=2
startblock=0
endblock=0
volindex=1
The SD then says this:
BxSdGate: fd_cmds.c:360-0 === Bootstrap file ===
BxSdGate: fd_cmds.c:362-0 Volume="E85-704"
BxSdGate: fd_cmds.c:362-0 MediaType="EXB8500c"
BxSdGate: fd_cmds.c:362-0 Device="EXB8505-00"
BxSdGate: fd_cmds.c:362-0 VolSessionId=144
BxSdGate: fd_cmds.c:362-0 VolSessionTime=1202096137
BxSdGate: fd_cmds.c:362-0 VolFile=0-2
BxSdGate: fd_cmds.c:362-0 VolBlock=0
BxSdGate: fd_cmds.c:362-0 FileIndex=1
BxSdGate: fd_cmds.c:362-0 Count=1
BxSdGate: fd_cmds.c:366-0 === end bootstrap file ===
..
BxSdGate: parse_bsr.c:180-0 Leave parse_bsf()
Next : 0x0
Root bsr : 0x80f4598
VolumeName : E85-704
MediaType : EXB8500c
Device : EXB8505-00
Slot : 0
SessId : 144
SessTime : 1202096137
VolFile : 0-2
VolBlock : 0-0
FileIndex : 1
count : 1
found : 0
done : no
positioning : 1
fast_reject : 1
..
It then finds an appropriate drive, finds the tape, checks the label,
and then:
BxSdGate: record.c:465-0 Enter read_record_block: remlen=64320 data_len=156
rem=0 blkver=2
BxSdGate: record.c:525-0 rd_rec_blk() got FI=1 SessId=138 Strm=UATTR len=72
remlen=64308 data_len=0
BxSdGate: record.c:584-0 Rtn full rd_rec_blk FI=1 SessId=138 Strm=UATTR len=72
BxSdGate: match_bsr.c:352-0 Fail on sessid. bsr=144 rec=138
BxSdGate: match_bsr.c:198-0 No nxt_bsr use_pos=1 repos=0
This one repeats some 10'000 times, until finally it reaches SessId
144, restores the file and is done.
It looks to me that the VolFile="0-2" is the problem, as it seems to
say to actually read all three jobs on the tape?!
If this is so, then the "startfile" entry in the "jobmedia" table
would be the source of the problem.
And actually, changing that value to 2 makes fsf happen. Fine.
Now when i look at the "jobmedia" table, I see that all "startfile"
entries are 0, except on jobs which are bigger 1GB, where the 2nd and
following records have entries != 0.
As far as my records in the catalog show, all startfile entries should
be equal to endfile. One could easily patch this with some catalog
cleanup script.
But the interesting question is: why does it happen?
rgds,
PMc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
