Il giorno mer, 25/09/2019 alle 21.36 +0200, Jens Axboe ha scritto:
> On 9/25/19 9:30 PM, Alan Stern wrote:
> [...]
> >
> > I have attached the two patches to this email. You should start
> with a
> > recent kernel source tree and apply the patches by doing:
> >
> > git apply patch1 patch2
>
On 9/25/19 9:30 PM, Alan Stern wrote:
> On Fri, 20 Sep 2019, Andrea Vai wrote:
>
>> Il giorno gio, 19/09/2019 alle 14.14 +, Damien Le Moal ha scritto:
>>> On 2019/09/19 16:01, Alan Stern wrote:
>>> [...]
No doubt Andrea will be happy to test your fix when it's ready.
>>
>> Yes, of course.
On Fri, 20 Sep 2019, Andrea Vai wrote:
> Il giorno gio, 19/09/2019 alle 14.14 +, Damien Le Moal ha scritto:
> > On 2019/09/19 16:01, Alan Stern wrote:
> > [...]
> > > No doubt Andrea will be happy to test your fix when it's ready.
>
> Yes, of course.
>
> >
> > Hannes posted an RFC series:
>
On Fri, Sep 20, 2019 at 09:25:17AM +0200, Andrea Vai wrote:
> Il giorno gio, 19/09/2019 alle 13.54 -0400, Alan Stern ha scritto:
> >
> > In general, USB flash drives should not be expected to work as well
> > as
> > an actual disk drive connected over USB.
>
> Ok, so I think I'll buy some differ
Il giorno gio, 19/09/2019 alle 13.54 -0400, Alan Stern ha scritto:
>
> In general, USB flash drives should not be expected to work as well
> as
> an actual disk drive connected over USB.
Ok, so I think I'll buy some different hardware. Would an SSD drive
(connected over USB) behave like a flash
Il giorno gio, 19/09/2019 alle 14.14 +, Damien Le Moal ha scritto:
> On 2019/09/19 16:01, Alan Stern wrote:
> [...]
> > No doubt Andrea will be happy to test your fix when it's ready.
Yes, of course.
>
> Hannes posted an RFC series:
>
> https://www.spinics.net/lists/linux-scsi/msg133848.htm
On Thu, 19 Sep 2019, Andrea Vai wrote:
> BTW, another question: Alan refers to the slow media as a "consumer-
> grade USB storage device". What could I do to identify and buy a "good
> media"? Are there any features to look for?
In general, USB flash drives should not be expected to work as well
On 2019/09/19 16:01, Alan Stern wrote:
> On Thu, 19 Sep 2019, Damien Le Moal wrote:
>
>>> This is exactly the sort of difference one might expect to see from
>>> the commit f664a3cc17b7 ("scsi: kill off the legacy IO path") you
>>> identified as the cause of the problem. With multiqueue I/O, it's
On Thu, 19 Sep 2019, Damien Le Moal wrote:
> > This is exactly the sort of difference one might expect to see from
> > the commit f664a3cc17b7 ("scsi: kill off the legacy IO path") you
> > identified as the cause of the problem. With multiqueue I/O, it's not
> > surprising to see multiple sequen
On Thu, Sep 19, 2019 at 09:09:33AM +, Damien Le Moal wrote:
> On 2019/09/19 10:56, Ming Lei wrote:
> > On Thu, Sep 19, 2019 at 08:26:32AM +, Damien Le Moal wrote:
> >> On 2019/09/18 18:30, Alan Stern wrote:
> >>> On Wed, 18 Sep 2019, Andrea Vai wrote:
> >>>
> > Also, I wonder if the cha
On 2019/09/19 10:56, Ming Lei wrote:
> On Thu, Sep 19, 2019 at 08:26:32AM +, Damien Le Moal wrote:
>> On 2019/09/18 18:30, Alan Stern wrote:
>>> On Wed, 18 Sep 2019, Andrea Vai wrote:
>>>
> Also, I wonder if the changing the size of the data transfers would
> make any difference. This
On Thu, Sep 19, 2019 at 08:26:32AM +, Damien Le Moal wrote:
> On 2019/09/18 18:30, Alan Stern wrote:
> > On Wed, 18 Sep 2019, Andrea Vai wrote:
> >
> >>> Also, I wonder if the changing the size of the data transfers would
> >>> make any difference. This is easy to try; just write "64" to
> >>
On 2019/09/18 18:30, Alan Stern wrote:
> On Wed, 18 Sep 2019, Andrea Vai wrote:
>
>>> Also, I wonder if the changing the size of the data transfers would
>>> make any difference. This is easy to try; just write "64" to
>>> /sys/block/sd?/queue/max_sectors_kb (where the ? is the appropriate
>>> dr
Il giorno mer, 18/09/2019 alle 12.30 -0400, Alan Stern ha scritto:
> On Wed, 18 Sep 2019, Andrea Vai wrote:
> [...]
> > BAD:
> > Logs: log_10trials_50MB_BAD_NonCanc_64.txt,
> > log_10trials_50MB_BAD_NonCanc_non64.txt
> > 64: 34, 34, 35, 39, 37, 32, 42, 44, 43, 40
> > not64: 61, 71, 59, 71, 62
On Wed, 18 Sep 2019, Andrea Vai wrote:
> > Also, I wonder if the changing the size of the data transfers would
> > make any difference. This is easy to try; just write "64" to
> > /sys/block/sd?/queue/max_sectors_kb (where the ? is the appropriate
> > drive letter) after the drive is plugged in b
Il giorno lun 26 ago 2019 alle ore 18:33 Alan Stern <
st...@rowland.harvard.edu> ha scritto:
> [...]
> In fact, even the traces where the file doesn't exist beforehand
> show
> some delays. Just not as many delays as the traces where the file
> does
> exist. And again, each delay is in the midd
Il giorno mar, 20/08/2019 alle 13.13 -0400, Alan Stern ha scritto:
> On Mon, 19 Aug 2019, Andrea Vai wrote:
>
> > Hi Alan,
> > I attach the two traces, collected as follows:
> >
> > - start the trace;
> > - wait 10 seconds;
> > - plug the drive;
> > - wait 5 seconds;
> > - mount the drive;
> >
On Tue, Jul 09, 2019 at 11:18:38PM +0200, Andrea Vai wrote:
> On 08/07/19 09:01:35, Ming Lei wrote:
> > > > > > > > >
> > > > > > > > > commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
> > > > > > > > >
> > > > > > > > > [...]
> >
> > 1) run the bcc biosnoop trace in one terminal after mount
On 08/07/19 09:01:35, Ming Lei wrote:
> > > > > > > >
> > > > > > > > commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
> > > > > > > >
> > > > > > > > [...]
>
> 1) run the bcc biosnoop trace in one terminal after mounting the fs on the
> USB dirve
>
> 2) start the write test in another tem
On Sun, 7 Jul 2019, Andrea Vai wrote:
> On 03/07/19 10:23:13, Alan Stern wrote:
> >
> > [...]
> > Andrea, another thing you could try is to collect a usbmon trace under
> > one of the "slow" kernels. Follow the instructions in
> > Documentation/usb/usbmon.txt. I think you could kill the file-
On Sat, Jul 06, 2019 at 11:33:27AM +0200, Andrea Vai wrote:
> On 03/07/19 14:36:05, Ming Lei wrote:
> > On Wed, Jul 03, 2019 at 07:11:17AM +0200, Andrea Vai wrote:
> > > On 03/07/19 10:01:23, Ming Lei wrote:
> > > > On Wed, Jul 03, 2019 at 12:39:31AM +0200, Andrea Vai wrote:
> > > > > On 02/07/19 2
On 03/07/19 10:23:13, Alan Stern wrote:
>
> [...]
> Andrea, another thing you could try is to collect a usbmon trace under
> one of the "slow" kernels. Follow the instructions in
> Documentation/usb/usbmon.txt. I think you could kill the file-copy
> operation after just a couple of seconds; t
On 03/07/19 14:36:05, Ming Lei wrote:
> On Wed, Jul 03, 2019 at 07:11:17AM +0200, Andrea Vai wrote:
> > On 03/07/19 10:01:23, Ming Lei wrote:
> > > On Wed, Jul 03, 2019 at 12:39:31AM +0200, Andrea Vai wrote:
> > > > On 02/07/19 20:01:13, Ming Lei wrote:
> > > > > On Tue, Jul 02, 2019 at 12:46:45PM
On Wed, Jul 3, 2019 at 12:36 AM Ming Lei wrote:
>
> BTW, 'rotational' shouldn't be set for USB drive, except for USB HDD,
> but that shouldn't be related with your issue.
I get
/sys/block/sdb/queue/rotational:1
for all USB flash drives on all computers with every kernel since
forever, including 5
On Wed, 3 Jul 2019, Johannes Thumshirn wrote:
> On Wed, Jul 03, 2019 at 12:36:30AM +0200, Andrea Vai wrote:
> > On 02/07/19 13:51:17, Johannes Thumshirn wrote:
> > > On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > > > Hi,
> > > > I have a problem writing data to a USB pendrive, a
On Wed, Jul 03, 2019 at 12:36:30AM +0200, Andrea Vai wrote:
> On 02/07/19 13:51:17, Johannes Thumshirn wrote:
> > On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > > Hi,
> > > I have a problem writing data to a USB pendrive, and it seems
> > > kernel-related. With the help of Greg a
On Wed, Jul 03, 2019 at 07:11:17AM +0200, Andrea Vai wrote:
> On 03/07/19 10:01:23, Ming Lei wrote:
> > On Wed, Jul 03, 2019 at 12:39:31AM +0200, Andrea Vai wrote:
> > > On 02/07/19 20:01:13, Ming Lei wrote:
> > > > On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > > > > Hi,
> > > > >
On 03/07/19 10:01:23, Ming Lei wrote:
> On Wed, Jul 03, 2019 at 12:39:31AM +0200, Andrea Vai wrote:
> > On 02/07/19 20:01:13, Ming Lei wrote:
> > > On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > > > Hi,
> > > > I have a problem writing data to a USB pendrive, and it seems
> > > >
On Wed, Jul 03, 2019 at 12:39:31AM +0200, Andrea Vai wrote:
> On 02/07/19 20:01:13, Ming Lei wrote:
> > On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > > Hi,
> > > I have a problem writing data to a USB pendrive, and it seems
> > > kernel-related. With the help of Greg an Alan (th
On 02/07/19 13:51:17, Johannes Thumshirn wrote:
> On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > Hi,
> > I have a problem writing data to a USB pendrive, and it seems
> > kernel-related. With the help of Greg an Alan (thanks) and some
> > bisect, I found out the offending commit
On 02/07/19 20:01:13, Ming Lei wrote:
> On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> > Hi,
> > I have a problem writing data to a USB pendrive, and it seems
> > kernel-related. With the help of Greg an Alan (thanks) and some
> > bisect, I found out the offending commit being
> >
On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> Hi,
> I have a problem writing data to a USB pendrive, and it seems
> kernel-related. With the help of Greg an Alan (thanks) and some
> bisect, I found out the offending commit being
>
> commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
On Tue, Jul 02, 2019 at 12:46:45PM +0200, Andrea Vai wrote:
> Hi,
> I have a problem writing data to a USB pendrive, and it seems
> kernel-related. With the help of Greg an Alan (thanks) and some
> bisect, I found out the offending commit being
>
> commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6
33 matches
Mail list logo
