Re: [PATCH] [SCSI] st: expand ability to write immediate filemarks

["Kai Mäkisara" <kai.makisara@kolumbus.fi>]

On 02/29/2012 12:03 AM, Lee Duncan wrote:
> Hi Kai:
>
> Thanks for your response ...
>
> On 02/28/2012 11:40 AM, Kai Makisara wrote:
>> On Wed, 15 Feb 2012, Lee Duncan wrote:
>>
>>> The st tape driver recently added the MTWEOFI ioctl, which writes
>>> a tape filemark (EOF), like the MTWEOF ioctl, except that MTWEOFI
>>> returns immediately. This makes certain applications, like backup
>>> software, run much more quickly on buffered tape drives.
>>>
...
>>>
>>>   static int st_dev_max;
>>>   static int st_nr_dev;
>>> @@ -103,6 +104,8 @@ module_param_named(max_sg_segs, max_sg_segs, int, 0);
>>>   MODULE_PARM_DESC(max_sg_segs, "Maximum number of scatter/gather segments to use (256)");
>>>   module_param_named(try_direct_io, try_direct_io, int, 0);
>>>   MODULE_PARM_DESC(try_direct_io, "Try direct I/O between user buffer and tape drive (1)");
>>> +module_param_named(st_nowait_eof, st_nowait_eof, int, 0);
>>> +MODULE_PARM_DESC(st_nowait_eof, "Do not wait when writing EOF (filemark) (0)");
>>>
>>
>> I think this should not be a module option. The property should be
>> settable only as a mode option like other options of this kind.
>> (I may have not written this clearly in my previous reply).
>>
>
> I respectfully disagree.
>
> There are legacy applications, such as the IBM network backup program that sparked this
> bug fix. Such applications do not know about the capability added by this patch, just as
> they do not know about the relatively new MTWEOFI ioctl. Hence the module option is a
> convenient method for such applications to achieve increased throughput.
>
You may not have fully understood what there mode options mean in 
practice. For each physical tape, you have up to four different device
files (modes; eight if you count both auto-rewind and non-rewind 
devices). Each can be programmed with different characteristics using 
the ioctls. For instance, you can have /dev/nst0a which uses "normal" 
WEOF and /dev/nst0b which uses immediate WEOF. If you want the program 
to benefit from immeadiate WEOFs, you tell it to use /dev/nst0b. The 
program does not have to know anything about the new options.

The system should configure the devices when detected, according to the 
choices made by the system manager. I once made a proof-of-concept 
program stinit for this purpose. mt can also be used for this. The trend 
is systems has for tens of years to move from boot-time configuration to 
run-time configuration.

> I agree there is a small risk of loosing errors or error context when writing immediate
> filemarks, but is the same problem that already exists in the case of the MTWEOFI ioctl.
>
Yes, but in case of MWEOFI, the programmer takes a calculated risk. For 
instance, he/she can use MTWEOF for the last filemark to catch the 
errors (or just look at possible errors from close()). The defaults are 
safe. In case of a module option, the default for the unsuspecting user 
is unsafe.

> I would be glad to add a section in the st documentation that mentions the dangers of
> writing immediate filemarks, if you think that would help clarify usage of this feature.
>
It helps clarity but it does not remove the danger.

Kai