Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds

[Joerg Wunsch]

"Kenneth D. Merry" <ken at FreeBSD.ORG> wrote:

>> (Replacing the L9 by some SAS-attached LTO-x library is already
>> planned.)
> 
> Yep, you'll get much more capacity that way.

That's the main reason, yes.  My pile of DLT media is getting quite full.

> I have attached an updated DTrace script.  This will print out the info
> field, and we'll see what the drive is returning in the info field.

Here's the output (this time, "mt fsf 32767" first, and the "dd" command
second).

root at uriah:~ # dtrace -s /tmp/tapetest.d
dtrace: script '/tmp/tapetest.d' matched 2 probes
CPU     ID                    FUNCTION:NAME
  1    406                    saerror:entry Opcode 11, Status 0xc Data: Len 0, Resid 0, Sense: Len 252, Resid 223

  1  21086        scsi_get_sense_info:entry Sense info: 0,0,7f,fa

  3    406                    saerror:entry Opcode 08, Status 0xc Data: Len 65536, Resid 55296, Sense: Len 252, Resid 223

  3  21086        scsi_get_sense_info:entry Sense info: 0,0,d8,0

^C

> If the residual value in the info field is correct, then we may have a
> problem with the way that scsi_get_sense_info() is handling it.

I think that's the case; the sense info looks OK to me, and makes sense (:-);
32762 for the SPACE command, 55296 for the READ which is 64 KiB - 10 KiB.

I'll look into scsi_get_sense_info().
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)