From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Andy Shevchenko <ext-andriy.shevchenko@nokia.com>,
Denis Karpov <ext-denis.2.karpov@nokia.com>,
Adrian Hunter <adrian.hunter@nokia.com>,
Alan Stern <stern@rowland.harvard.edu>,
David Brownell <dbrownell@users.sourceforge.net>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-usb@vger.kernel.org
Subject: Re: [PATCHv2] usb: gadget: storage: optional SCSI WRITE FUA bit
Date: Wed, 14 Jul 2010 16:24:23 +0200 [thread overview]
Message-ID: <op.vft7mxqm7p4s8u@pikus> (raw)
In-Reply-To: <AANLkTil1eG5yzBxvryf-TZINYjeGph-rNz8eELQtm5tj@mail.gmail.com>
On Wed, 14 Jul 2010 15:44:58 +0200, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> @@ -93,6 +93,8 @@
>>> * removable Default false, boolean for removable media
>>> * luns=N Default N = number of filenames, number of
>>> * LUNs to support
>>> + * 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?
>>> + ssize_t rc = count;
>> Not really needed here.
> See below
This still stands. The “rc” is not needed.
>>> + 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().
>>> +
>>> + 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);
> Actually fua = 1 means ignorance of that flag.
ignore_fua would be better name then I think. This also stands for
module parameter.
--
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--
next prev parent reply other threads:[~2010-07-14 14:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 8:36 [PATCH] usb: gadget: storage: optional SCSI WRITE FUA bit Andy Shevchenko
2010-07-13 14:09 ` Alan Stern
2010-07-14 9:05 ` [PATCHv2] " Andy Shevchenko
2010-07-14 12:38 ` Michał Nazarewicz
2010-07-14 13:44 ` Andy Shevchenko
2010-07-14 13:55 ` Roger Quadros
2010-07-16 7:54 ` Felipe Balbi
2010-07-16 8:38 ` Roger Quadros
2010-07-14 14:24 ` Michał Nazarewicz [this message]
2010-07-14 15:05 ` Andy Shevchenko
2010-07-14 17:12 ` Michał Nazarewicz
2010-07-15 9:07 ` [PATCHv3 1/2] usb: gadget: storage: strict coversion of 'ro' parameter Andy Shevchenko
2010-07-15 9:07 ` [PATCHv3 2/2] usb: gadget: storage: optional SCSI WRITE FUA bit Andy Shevchenko
2010-07-21 19:17 ` Greg KH
2010-07-22 8:58 ` [PATCHv4 1/2] usb: gadget: storage: strict coversion of 'ro' parameter Andy Shevchenko
2010-07-22 8:58 ` [PATCHv4 2/2] usb: gadget: storage: optional SCSI WRITE FUA bit Andy Shevchenko
2010-07-22 14:13 ` Alan Stern
2010-07-22 14:27 ` Andy Shevchenko
2010-07-22 14:53 ` [PATCHv5] " Andy Shevchenko
2010-07-22 14:07 ` [PATCHv4 1/2] usb: gadget: storage: strict coversion of 'ro' parameter Alan Stern
2010-07-22 14:17 ` Michał Nazarewicz
2010-07-21 19:17 ` [PATCHv3 " Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.vft7mxqm7p4s8u@pikus \
--to=m.nazarewicz@samsung.com \
--cc=adrian.hunter@nokia.com \
--cc=andy.shevchenko@gmail.com \
--cc=dbrownell@users.sourceforge.net \
--cc=ext-andriy.shevchenko@nokia.com \
--cc=ext-denis.2.karpov@nokia.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.