From owner-freebsd-scsi@FreeBSD.ORG Wed Jul 30 19:19:17 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1528B22 for ; Wed, 30 Jul 2014 19:19:17 +0000 (UTC) Received: from uriah.heep.sax.de (uriah.heep.sax.de [IPv6:2a01:170:1047::9]) by mx1.freebsd.org (Postfix) with ESMTP id 5FBFB292A for ; Wed, 30 Jul 2014 19:19:17 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 9B944267B; Wed, 30 Jul 2014 21:19:15 +0200 (CEST) Mime-Version: 1.0 Sender: j@uriah.heep.sax.de X-Newsreader: knews 1.0b.1 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <20140729090724.GA26577@uriah.heep.sax.de> <201407291823.s6TINAad032318@higson.cam.lispworks.com> <20140729191829.GK3121@uriah.heep.sax.de> <20140729204354.GA78616@nargothrond.kdm.org> <20140729224414.E2AAE276@uriah.heep.sax.de> <20140730035230.GA81800@nargothrond.kdm.org> <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> In-Reply-To: <20140730153229.GA86368@nargothrond.kdm.org> From: freebsd-scsi@uriah.heep.sax.de (Joerg Wunsch) Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds X-Original-Newsgroups: local.freebsd.scsi To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=us-ascii Message-Id: <20140730191915.9B944267B@uriah.heep.sax.de> Date: Wed, 30 Jul 2014 21:19:15 +0200 (CEST) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 19:19:17 -0000 "Kenneth D. Merry" 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@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. ;-)