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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
