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

[Lee Duncan <lduncan@suse.com>]

Kai:

Your argument makes sense. I will resubmit the patch without the module
variable, and with a little more added to the documentation concerning
the possible dangers of writing immediate EOFs.

On 02/28/2012 11:05 PM, Kai Mäkisara wrote:
> 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
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Lee Duncan
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html