Bug 128568

Summary: [PATCH] ANSI EOF support
Product: Red Hat Enterprise Linux 3 Reporter: Bastien Nocera <bnocera>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: petrides, riel, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://linux.web.cern.ch/linux/documentation/patches/linux-2.4.20-cern-tape_ansi_eof.patch
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-03 15:33:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
jwltest-st-ansi-eof.patch none

Description Bastien Nocera 2004-07-26 15:41:57 UTC
This is a patch for ANSI EOF support for tape devices.
Applies against upstream 2.4.20.

Patch is in the URL field. (cut'n'paste below)

Index: drivers/scsi/st.c
===================================================================
--- drivers/scsi/st.c	(.../trunk/cernlinux)	(revision 17)
+++ drivers/scsi/st.c	(.../branches/cernlinux/tape_ansi_eof)	(revision 17)
@@ -3367,6 +3367,9 @@
 		}
 
 		STp->recover_reg = 0;		/* Clear after read */
+		/* Support ANSI End-of-Volume processing.
+		 * Originally by Fabien Collin. */
+		STps->eof = ST_NOEOF;
 		retval = 0;
 		goto out;
 	}			/* End of MTIOCGET */

Comment 4 John W. Linville 2005-04-29 15:08:13 UTC
I'm curious...was this patch ever posted upstream?  If so, why was it not 
accepted? 

Comment 5 John W. Linville 2005-04-29 18:54:10 UTC
Test kernels are available here: 
 
   http://people.redhat.com/linville/kernels/rhel3/ 
 
Please give them a try and post the results.  Thanks! 

Comment 8 John W. Linville 2005-05-11 18:52:20 UTC
Still need a report on the kernels from comment 5... 

Comment 13 John W. Linville 2005-06-27 19:27:19 UTC
Posted patch to linux-scsi.org and upstream st maintainer for
comment on 6/27/2005...

Comment 14 John W. Linville 2005-06-29 18:14:01 UTC
Response from Kai Makisara, upstream st driver maintainer: 
 
 The ANSI labelled tape standard specifies that the EOD on tape must be 
> preceeded by a trailer label.  If during writing your application hits 
> LEOT (Logical End Of Tape), it must be able to write the trailer label. 
> However with the default tape driver (st), you cannot write anything 
> after the LEOT. 
 
This is not true. Quoting from linux/Documentation/scsi/st.txt: 
 
"When the end of medium early warning is encountered, the current write 
is finished and the number of bytes is returned. The next write 
returns -1 and errno is set to ENOSPC. To enable writing a trailer, 
the next write is allowed to proceed and, if successful, the number of 
bytes is returned. After this, -1 and the number of bytes are 
alternately returned until the physical end of medium (or some other 
error) is encountered." 
 
(Yes, this should be added to the man page ;-) 
 
> So the patch clears the error condition so that the 
> application can write the trailer label (there is some space available 
> on tape media between LEOT and PEOT=Physical End Of Tape). 
> 
If this new way is what users want and it does not break existing 
applications, it should be added. Especially if it is the way some other 
common system behaves. However, when the semantics are changed, the 
documentation in the kernel sources should also be updated. 
 

Comment 15 John W. Linville 2005-06-29 18:23:27 UTC
Although he is referring to the upstream 2.6 kernel, I don't think the RHEL3 
version of the driver is significantly different in this respect.  So, given 
the quote from Documentation/scsi/st.txt, it seems that the proposed patch is 
unnecessary.  Do you agree? 
 
If not, then please elaborate on how/why it is unacceptable to recode your 
application in that fashion.  We will also need to augment the proposed patch 
to account for documentation needs and re-post it upstream.  Lather.  Rinse.  
Repeat. 
 
I will now boldly presume that the quoted method is sufficient and close this 
as NOTABUG.  If you disagree, please reopen it and include the information 
requested above. 

Comment 16 John W. Linville 2005-07-01 16:50:35 UTC
From customer: 
 
Bartlomiej compared RHEL3 and 2.6. 
 
st.c in RHEL3 2.4.21-32.0.1.EL: 
 
/* Write command */ 
static ssize_t st_write(struct file *filp, const char *buf, size_t count, 
loff_t * ppos) 
{ 
... 
 
        if (STps->eof == ST_EOM_OK) { 
                retval = (-ENOSPC); 
                goto out; 
        } 
... 
} 
 
upstream 2.6: 
/* Write command */ 
static ssize_t st_write(struct file *filp, const char __user *buf, size_t 
count, loff_t * ppos) 
{ 
... 
        if (STps->eof == ST_EOM_OK) { 
                STps->eof = ST_EOD_1;  /* allow next write */ 
                retval = (-ENOSPC); 
                goto out; 
        } 
... 
} 
 
In RHEL3 you always hit "if (STps->eof == ST_EOM_OK)" and 
therefore writing the trailing label is impossible. 
 
Peter 

Comment 17 John W. Linville 2005-07-01 17:03:36 UTC
Created attachment 116246 [details]
jwltest-st-ansi-eof.patch

Revised patch to reflect current upstream behaviour...

Comment 18 John W. Linville 2005-07-01 17:39:23 UTC
Test kernels with the new patch are available here: 
 
   http://people.redhat.com/linville/kernels/rhel3/ 
  
Please give them a try and post the results.  Thanks! 

Comment 19 John W. Linville 2005-08-03 15:33:48 UTC
Closed due to inactivity.  Please reopen when requested test results become 
available.  Thanks!