Re: Slow I/O on USB media

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jun 06, 2019 at 04:00:52PM +0200, Andrea Vai wrote:
> Il giorno mer, 05/06/2019 alle 19.39 +0200, Greg KH ha scritto:
> > On Wed, Jun 05, 2019 at 06:23:58PM +0200, Andrea Vai wrote:
> > [...]
> > 
> > > Anyway, I know that I can do all of this in a better way, and will
> > let
> > > you know.
> > 
> > Yes, please do so, your steps above do not show much.
> 
> Here I am with another question.
> What I have done so far:
> 
> - booted with the last kernel I know to be working (4.20.13-
> 200.fc29.x86_64, installed from Fedora repos), checked that test runs

We have no idea what is in a random distro kernel, sorry.

So I would start with a kernel.org kernel.  That keeps things at an even
level, and you are using a "known good" configuration as well.

> fine (2min to copy)
> - marked "git bisect good v4.20.13"
> - built the latest stable version:
>   - git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   - cp -v /boot/config-$(uname -r) .config
>   - make -j4 && make modules_install && make install && grub2-mkconfig -o /boot/grub2/grub.cfg
>   - grubby --set-default /boot/vmlinuz-5.2.0-rc3 (the last regular file listed in "ls -lrt /boot/v*")
> - rebooted with kernel 5.2.0-rc3, ran the test, took 49min to copy
> (!), thus marked "git bisect bad"
> - built again, and it turns out to be 4.20.0 (why is it earlier than
> 4.20.13?), rebooted with 4.20.0, ran the test and it took more than 15
> minutes so I killed the cp process, and marked it BAD, and obtained:
> 
> The merge base 8fe28cb58bcb235034b64cbbb7550a8a43fd88be is bad.
> This means the bug has been fixed between
> 8fe28cb58bcb235034b64cbbb7550a8a43fd88be and
> [0f7c162c1df596e0bba04c26fc9cc497983bf32b].
> 
> The output of "git bisect log" is:
> 
> git bisect start
> # good: [0f7c162c1df596e0bba04c26fc9cc497983bf32b] Linux 4.20.13
> git bisect good 0f7c162c1df596e0bba04c26fc9cc497983bf32b
> # bad: [f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a] Linux 5.2-rc3
> git bisect bad f2c7c76c5d0a443053e94adb9f0918fa2fb85c3a
> # bad: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20
> git bisect bad 8fe28cb58bcb235034b64cbbb7550a8a43fd88be
> 
> I can understand that the bug was present before 4.20.13 (is that
> reasonable?), but how can I tell bisect to start at 4.20.13, which I
> know for sure to be working, and not from 4.20.0, which I actually
> don't care about?
> 
> I am afraid I am missing something obvious, sorry

As Alan said, 4.20 is older than 4.20.13.

But, is the kernel.org version of 4.20.13 really "good" here?

I would start with Linus's tree and stay away from the stable trees
for now.  As you end up with odd "leafs" that can confuse 'git bisect'
and everyone else.

So start with 4.20.0.  Test that.  If it is "good", then great!

If not, then maybe you are not really using the same kernel
configuration that Fedora is, _or_ Fedora has some odd kernel patch
added that makes things an order of magnitude faster :)

thanks,

greg k-h