linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Andrea Vai <andrea.vai@unipv.it>
Cc: linux-usb@vger.kernel.org
Subject: Re: Slow I/O on USB media
Date: Tue, 4 Jun 2019 07:43:00 +0200	[thread overview]
Message-ID: <20190604054300.GE1588@kroah.com> (raw)
In-Reply-To: <86676f40a8c1aa44bf5799eac6019183d6d33336.camel@unipv.it>

On Mon, Jun 03, 2019 at 01:13:48PM +0200, Andrea Vai wrote:
> Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha scritto:
> > [...]
> Hi,
> 
> > Any chance you can use 'git bisect' to find the offending commit?
> Yes, I am doing it as I managed to build the kernel from source

Great!  What did you find?

> > And did you accidentally turn on "sync" for the filesystem? 
> Sorry, I don't think so but actually I don't know exactly what it is
> nor how to check it...
> 
> >  How do you
> > know the old kernel really flushed the buffers out in 1 minute? 
> 
> I used to try to unmount the usb media (e.g. "eject" using Nautilus
> file manager), and got a message stating the filesystem was in use and
> could not be mounted, so always answered to not eject it until it was
> unmounted without any warning... does it make sense?

That does not mean that the data is not flushed to the device yet, that
just means that some userspace program is still accessing the device.
You need to run some other type of test to validate how long it taks for
the data to get to the device.

> >  But 12
> > minutes is really long, did anything else change in your userspace
> > between the kernel changes as well?
> I am not sure if I understand correctly the "userspace" you mention:
> if you mean my home directory and contents, settings etc, then yes,
> maybe... but while I am doing the tests I am quite sure I didn't
> change anything, and double-checked many times that the 4.20 kernel is
> always working (I usually boot up with it when I need to do the usual
> day work).

I mean, did any other programs on your machine change between the
upgrade of your kernel?  Maybe some gnome-tracker is going off and
indexing all of the data on that device after you mount it, and it
wasn't previously doing that before.  As it is still busy, something has
some open files on that device.

good luck!

greg k-h

  reply	other threads:[~2019-06-04  5:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30 13:18 Slow I/O on USB media Andrea Vai
2019-05-30 13:25 ` Greg KH
2019-06-03 11:13   ` Andrea Vai
2019-06-04  5:43     ` Greg KH [this message]
2019-06-04  7:26       ` Andrea Vai
2019-06-05  7:36       ` Andrea Vai
2019-06-05 14:26         ` Alan Stern
2019-06-05 15:46           ` Andrea Vai
2019-06-05 16:11             ` Alan Stern
2019-06-05 14:55         ` Greg KH
     [not found]           ` <0c2adde7154b0a6c8b2ad7fc5258916731b78775.camel@unipv.it>
2019-06-05 16:23             ` Andrea Vai
2019-06-05 17:39               ` Greg KH
2019-06-06  8:41                 ` Andrea Vai
2019-06-06  9:03                 ` Andrea Vai
2019-06-06 14:00                 ` Andrea Vai
2019-06-06 14:30                   ` Alan Stern
2019-06-06 14:47                   ` Greg KH
2019-06-07  7:59                     ` Andrea Vai
2019-06-08  7:43                     ` Andrea Vai
2019-06-08  9:29                       ` Andrea Vai
2019-06-10 14:38                         ` Greg KH
2019-06-11  6:48                           ` Andrea Vai
2019-06-10 14:40                         ` Alan Stern
2019-06-10 14:55                           ` Andrea Vai
2019-06-10 16:20                             ` Alan Stern
2019-06-17 15:52                           ` Andrea Vai
2019-06-17 16:14                             ` Alan Stern
2019-06-17 16:34                               ` Andrea Vai
2019-06-17 17:28                                 ` Alan Stern
2019-07-01 17:52                                   ` Andrea Vai
2019-07-01 18:57                                     ` Alan Stern
2019-06-10 14:37                       ` 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=20190604054300.GE1588@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=andrea.vai@unipv.it \
    --cc=linux-usb@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).