SCSI, st: modify tape driver to allow writing immediate filemarks

Add an st module option st_nowait_eof which defaults to 0. Setting this option to 1 tells the st driver not to wait when writing a filemark, which can result in much faster times on streaming tape drives.

Add an st module option st_nowait_eof which defaults to 0. Setting this option to 1 tells the st driver not to wait when writing a filemark, which can result in much faster times on streaming tape drives.

Legacy applications cannot take advantage of the newer MTWEOFI ioctl, so this patch gives such applications the ability to write an immediate EOF using the normal MTWEOF ioctl if they set st_nowait_eof=1.

Reference: https://bugzilla.novell.com/show_bug.cgi?id=688996

Quoted 3 lines · Lee Duncan

Add an st module option st_nowait_eof which defaults to 0. Setting this option to 1 tells the st driver not to wait when writing a filemark, which can result in much faster times on streaming tape drives.

trivial comments:

drivers/scsi/st.c

Quoted 1 line

drivers/scsi/st.c +0 -0

[]

drivers/scsi/st.c static int max_sg_segs; · line 84

Quoted 5 lines

drivers/scsi/st.c +1 -0

@@ -81,6 +81,7 @@ static int max_sg_segs;
 static int try_direct_io = TRY_DIRECT_IO;
 static int try_rdio = 1;
 static int try_wdio = 1;
+static int st_nowait_eof = 0;

Could be bool.

drivers/scsi/st.c static int check_tape(struct scsi_tape *STp, struct file *filp) · line 1114

Quoted 8 lines

drivers/scsi/st.c +3 -0

@@ -1106,6 +1109,11 @@ static int check_tape(struct scsi_tape *STp, struct file *filp)
                                     STp->drv_buffer));
 		}
 		STp->drv_write_prot = ((STp->buffer)->b_data[2] & 0x80) != 0;
+		if (!STp->drv_buffer && STp->immediate_filemark) {
+			printk(KERN_WARNING "%s: non-buffered tape: "
+			    "disabling writing immediate filemarks", name);

Needs terminating "\n" and it's better to coalesce the format and ignore 80 char lines to make arbitrary greps a bit easier.

Quoted 8 lines · Lee Duncan

Add an st module option st_nowait_eof which defaults to 0. Setting this option to 1 tells the st driver not to wait when writing a filemark, which can result in much faster times on streaming tape drives.

Legacy applications cannot take advantage of the newer MTWEOFI ioctl, so this patch gives such applications the ability to write an immediate EOF using the normal MTWEOF ioctl if they set st_nowait_eof=1.

Quoted 2 lines

Reference: https://bugzilla.novell.com/show_bug.cgi?id=688996

Is there a real application? I can't open your reference. (Yes, I know that this feature can speed up writing dramatically in some cases, but is there a case with legacy applications?)

Anyway, I don't think this should be implemented as a pure module option. The standard semantics specify that MTWEOF is a synchronization point and this module option breaks that for all users.

The driver supports several tape device files with different properties that can be set at run-time. Why not implement this as one of the mode options? This would allow the "normal" users to use a device file with synchronizing MTWEOF and the users needing unsynchronizing MTWEOF would use another device file.

The st driver exports the options in sysfs. This is important so that the users can check what the options for a device are. This new option should also be exported.

Kai

Quoted 12 lines · Kai Makisara

Quoted 10 lines · Lee Duncan

Add an st module option st_nowait_eof which defaults to 0. Setting this option to 1 tells the st driver not to wait when writing a filemark, which can result in much faster times on streaming tape drives.

Legacy applications cannot take advantage of the newer MTWEOFI ioctl, so this patch gives such applications the ability to write an immediate EOF using the normal MTWEOF ioctl if they set st_nowait_eof=1.

Reference: https://bugzilla.novell.com/show_bug.cgi?id=688996

Quoted 4 lines

Anyway, I don't think this should be implemented as a pure module option. The standard semantics specify that MTWEOF is a synchronization point and this module option breaks that for all users.

The Standard specifies that writing a filemark (i.e. an EOF) is a synchronization point if and only if the data is being written in immediate mode. In other words, you are not supposed to set both immediate writes and immediate EOFs. This is why I didn't overload the already-existing "immediate" flag in the driver.

I will add a check to the driver to disallow immediate EOFs if immediate writes are requested.