Prev: emacs and "linux" coding style
Next: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data
From: Andy Shevchenko on 14 Jul 2010 11:10 2010/7/14 Michał Nazarewicz <m.nazarewicz(a)samsung.com>: > On Wed, 14 Jul 2010 15:44:58 +0200, Andy Shevchenko > <andy.shevchenko(a)gmail.com> wrote: >>>> + * fua=b[,b...] Default false, booleans for ignore FUA >>>> flag >>>> + * in SCSI WRITE(6,10,12) commands >>> >>> I wonder if it makes sense to make it per-LUN. I would imagine >>> that it's great to ignore FUA if the device has its own power supply >>> in which case after disconnect the data won't be lost. This is a >>> per-device property not really per-LUN. As such I'd make this option >>> global for the gadget. > >> Make sense only for removable media with one partition. >> Otherwise. why we have sync option per partition f.e., not per device? > > Ah, OK, I see why this is per LUN. You want to be able not to ignore > FUA if the backing storage is a removable media, right? In instance, or vise versa. So, the user could decide if he wants to avoid this flag for one LUN or for another. >>>> + if (sscanf(buf, "%d", &i) != 1) >>>> + return -EINVAL; >>> Why not simple_strtol() directly? >> I did it in the same way like fsg_store_ro() does. >> I have no objections to back to previous solution. > OK. I'd use simpre_strol() myself. Maybe even patched fsg_store_ro(). Agree, but better to do series of patches then, I guess. >>>> + >>>> + if (curlun->fua) >>>> + fsg_lun_fsync_sub(curlun); > >>> Shouldn't that read something like: >>> >>> + if (!curlun->fua && i) >>> + fsg_lun_fsync_sub(curlun); >>> >>> ie. there is no sense in syncing if FUA was active (in which case all >>> writes were synced already, right?) or if the new value is false (since >>> then user does not won't syncing). > >> The idea is to sync data before switching from async mode. > > But there can be a case of switching from async to async when syncing > is not necessary. That's why I proposed the &&. With fua = 1 meaning > ignore the flag my proposal would be: > > + if (!i && curlun->fua) > + fsg_lun_fsync_sub(curlun); Makes sense. >> Actually fua = 1 means ignorance of that flag. > ignore_fua would be better name then I think. This also stands for > module parameter. I already thought about. Rather I agree with you. -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michał Nazarewicz on 14 Jul 2010 13:20 > 2010/7/14 Michał Nazarewicz <m.nazarewicz(a)samsung.com>: >> Ah, OK, I see why this is per LUN. You want to be able not to ignore >> FUA if the backing storage is a removable media, right? On Wed, 14 Jul 2010 17:05:07 +0200, Andy Shevchenko <andy.shevchenko(a)gmail.com> wrote: > In instance, or vise versa. I actually see the most sense in disabling FUA on devices with their own power supply for logical units which backing file is not (on) a removable device unless the removable device has some kind of lock (like CD-ROM's door). Either way, I now see the point of having this option per-LUN. >>> Actually fua = 1 means ignorance of that flag. >> ignore_fua would be better name then I think. This also stands for >> module parameter. Or even “nofua”. The other solution would be to change the meaning to the opposite (1 meaning that FUA is not ignored). -- Best regards, _ _ | Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o | Computer Science, Michał "mina86" Nazarewicz (o o) +----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Balbi on 16 Jul 2010 04:00 Hi, On Wed, Jul 14, 2010 at 04:55:33PM +0300, Roger Quadros wrote: > file_storage driver does not deal with partitions. only mediums. it deals with backing files, no matter if it's a medium, partition or a file on a file system (using a loop-device). -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roger Quadros on 16 Jul 2010 04:40 On 07/16/2010 10:54 AM, ext Felipe Balbi wrote: > Hi, > > On Wed, Jul 14, 2010 at 04:55:33PM +0300, Roger Quadros wrote: >> file_storage driver does not deal with partitions. only mediums. > > it deals with backing files, no matter if it's a medium, partition or a > file on a file system (using a loop-device). > True, you are talking from the device side of the g_files_storage where it accesses backing files, I was talking from the USB side, where g_file_storage exposes LUNs or Mediums and not partitions. br, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 21 Jul 2010 15:20 On Thu, Jul 15, 2010 at 12:07:21PM +0300, Andy Shevchenko wrote: > MS Windows mounts removable storage in "Removal optimized mode" by > default. All the writes to the media are synchronous which is achieved > by setting FUA (Force Unit Access) bit in SCSI WRITE(10,12) commands. > This prevents I/O requests aggregation in block layer dramatically > decreasing performance. > > This patch brings an option to accept or ignore mentioned bit > a) via specifying module parameter "nofua", or > b) through sysfs entry > /sys/devices/platform/musb_hdrc/gadget/gadget-lun-N/nofua Any new sysfs entry needs a matching documentation entry in the Documentation/ABI/ directory. Care to resend these two patches, with that documentation change added as well? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: emacs and "linux" coding style Next: [PATCH v2 2/2] ux500: add ab8500-regulators machine specific data |