From owner-freebsd-scsi@FreeBSD.ORG Sat Jun 19 18:05:26 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02134106566C for ; Sat, 19 Jun 2010 18:05:26 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id B58658FC16 for ; Sat, 19 Jun 2010 18:05:25 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o5JI5OOW039018 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 19 Jun 2010 11:05:25 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C1D06DD.6090506@feral.com> Date: Sat, 19 Jun 2010 11:05:17 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.168.221.1]); Sat, 19 Jun 2010 11:05:25 -0700 (PDT) Subject: Re: sa: write returns 0 = LEOM? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 18:05:26 -0000 On 6/16/2010 3:52 PM, Dustin J. Mitchell wrote: > I'm investigating a user bug report in Amanda: > http://forums.zmanda.com/showthread.php?t=2832 > > The problem boils down to a write(2) call for a SCSI tape device > (/dev/nsa0) returning 0 after quite a bit of data and a number of > filemarks have been written. Jean-Louis suspected that this was an > early warning EOM indication, and that a subsequent write() would > succeed, with Amanda having been duly warned that a physical EOM is > coming up. But looking at scsi_sa.c, this doesn't seem to be the > case. It looks like an early warning would result in a successful > write instead, because resid is set to zero. > I did some more thinking and remembering about this- sorry, but it's really been years since I had to think about tape drives. The code in question notes that EOM (end of media) is pending so that the *next* write operation will get a full residual. So, yes, when you got a full residual back (no data moves), but no error, that is an EOM indicator for the user app.