From gibbs@narnia.plutotech.com  Sat Mar 28 13:15:39 1998
Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07344
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 28 Mar 1998 13:15:38 -0800 (PST)
          (envelope-from gibbs@narnia.plutotech.com)
Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id OAA19476; Sat, 28 Mar 1998 14:12:11 -0700 (MST)
Message-Id: <199803282112.OAA19476@narnia.plutotech.com>
Date: Sat, 28 Mar 1998 14:12:11 -0700 (MST)
From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Reply-To: gibbs@narnia.plutotech.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Patches to make dump understand ENOSPC
X-Send-Pr-Version: 3.2

>Number:         6156
>Category:       bin
>Synopsis:       Patches to make dump understand ENOSPC
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 28 13:20:04 PST 1998
>Closed-Date:    Wed Oct 4 20:06:57 PDT 2000
>Last-Modified:  Wed Oct 04 20:07:35 PDT 2000
>Originator:     Justin T. Gibbs
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Pluto Technologies International Inc.
>Environment:

	CAM SCSI environment or any other environment where the target
	dump device returns ENOSPC at EOT.

>Description:

	Dump doesn't treat ENOSPC as an EOT condition.  This prevents
	the "auto-size" feature of dump from working on devices that
	return ENOSPC at EOT.  The CAM tape driver does this as do
	other systems (Pyramids running OSx are mentioned in a comment
	in dump).

>How-To-Repeat:

	Perform a large dump to a small tape and watch it bail when
	ENOSPC is returned.

>Fix:

The patch is pretty simple.  Check errno if write returns -1 for ENOSPC
and handle it accordingly.  The only possible catch has to do with rmt
operations.  The code now extracts the errno number from the reply from
the remote rmt session and sets errno accordingly.  If, for some reason,
ENOSPC (28) is a different error code on the remote system, we may
behave unexpectedly.  Is ENOSPC standardized???
	
==== //depot/FreeBSD-current/src/sbin/dump/dumprmt.c#4 - //depot/cam/sbin/dump/dumprmt.c#3 ====
***************
*** 362,375 ****
  {
  	register char *cp;
  	char code[30], emsg[BUFSIZ];
  
  	rmtgets(code, sizeof (code));
  	if (*code == 'E' || *code == 'F') {
  		rmtgets(emsg, sizeof (emsg));
  		msg("%s: %s", cmd, emsg);
  		if (*code == 'F') {
  			rmtstate = TS_CLOSED;
- 			return (-1);
  		}
  		return (-1);
  	}
--- 362,376 ----
  {
  	register char *cp;
  	char code[30], emsg[BUFSIZ];
+ 	extern errno;
  
  	rmtgets(code, sizeof (code));
  	if (*code == 'E' || *code == 'F') {
  		rmtgets(emsg, sizeof (emsg));
  		msg("%s: %s", cmd, emsg);
+ 		errno = atoi(&code[1]);
  		if (*code == 'F') {
  			rmtstate = TS_CLOSED;
  		}
  		return (-1);
  	}
==== //depot/FreeBSD-current/src/sbin/dump/tape.c#6 - //depot/cam/sbin/dump/tape.c#5 ====
***************
*** 819,831 ****
  		     slave_number, size, writesize);
  #endif
  
  		if (eot_count > 0)
  			size = 0;
  
- 		/*
- 		 * fixme: Pyramids running OSx return ENOSPC
- 		 * at EOT on 1/2 inch drives.
- 		 */
  		if (wrote < 0) {
  			(void) kill(master, SIGUSR1);
  			for (;;)
--- 819,835 ----
  		     slave_number, size, writesize);
  #endif
  
+ 		/*
+ 		 * Handle ENOSPC as an EOT condition
+ 		 */
+ 		if (wrote < 0 && errno == ENOSPC) {
+ 			wrote = 0;
+ 			eot_count++;
+ 		}
+ 
  		if (eot_count > 0)
  			size = 0;
  
  		if (wrote < 0) {
  			(void) kill(master, SIGUSR1);
  			for (;;)

>Release-Note:
>Audit-Trail:

From: "Blaz Zupan" <blaz@medinet.si>
To: <freebsd-gnats-submit@freebsd.org>, <gibbs@narnia.plutotech.com>
Cc:  Subject: Re: bin/6156: Patches to make dump understand ENOSPC
Date: Wed, 9 Dec 1998 11:56:46 +0100

 I checked on Irix and Linux, both have ENOSPC set to 28. I don't have access
 to any other non-FreeBSD box to check this.
 
 But I do have problems with dump not detecting end-of-tape under FreeBSD
 2.2.8 with option -a, it simply stops with "I/O error". Actually I have yet
 to see dump ask me for a new tape...
 
 I will be putting this patch on my box as soon as the DAT is free and report
 if it fixes my problem.
 
 Blaz Zupan, blaz@medinet.si, http://home.amis.net/blaz
 Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia
 

From: "Blaz Zupan" <blaz@medinet.si>
To: <freebsd-gnats-submit@freebsd.org>, <gibbs@narnia.plutotech.com>
Cc:  Subject: Re: bin/6156: Patches to make dump understand ENOSPC
Date: Wed, 9 Dec 1998 16:06:56 +0100

 Unfortunatelly the patch did not fix my problems. After trying to dump 2.1GB
 of data to a 2GB tape I got:
 
   DUMP: write error 1951600 blocks into volume 1
   DUMP: Do you want to restart?: ("yes" or "no")   DUMP: "Yes" or "No"?
   DUMP: Do you want to restart?: ("yes" or "no") no
 
 Does this suggest that there is some other error than ENOSPC returned?
 
 Blaz Zupan, blaz@medinet.si, http://www.amis.net/staff/blaz
 Medinet d.o.o., Linhartova 21, 2000 Maribor, Slovenia
 
State-Changed-From-To: open->closed 
State-Changed-By: gibbs 
State-Changed-When: Wed Oct 4 20:06:57 PDT 2000 
State-Changed-Why:  
These changes were committed to dump several years ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=6156 
>Unformatted:
