Re: Slow I/O on USB media

[Andrea Vai <andrea.vai@unipv.it>]

Il giorno lun, 10/06/2019 alle 16.38 +0200, Greg KH ha scritto:
> On Sat, Jun 08, 2019 at 11:29:16AM +0200, Andrea Vai wrote:
> > Il giorno sab 8 giu 2019 alle ore 09:43 Andrea Vai
> > <andrea.vai@unipv.it> ha scritto:
> > >
> > >[...]
> > >
> > > Hi,
> > >   there is also something else I don't understand.
> > > Every time I build a kernel, then after booting it "uname -a"
> shows
> > > something like
> > >
> > > Linux [...] 4.19.0-rc5+ #12 SMP Sat Jun 8 00:26:42 CEST 2019
> x86_64
> > > x86_64 x86_64 GNU/Linux
> > >
> > > where the number after "#" increments by 1 from the previous
> build.
> > >
> > > Now I have the same number (#12) after a new build, is it
> normal?
> > > Furthermore, "ls -lrt /boot/v*" shows the last lines to be
> > >
> > > -rw-r--r--. 1 root root 8648656  8 giu 00.35 /boot/vmlinuz-
> 4.19.0-rc5+.old
> > > -rw-r--r--. 1 root root 8648656  8 giu 09.08 /boot/vmlinuz-
> 4.19.0-rc5+
> > >
> > > and "diff /boot/vmlinuz-4.19.0-rc5+.old /boot/vmlinuz-4.19.0-
> rc5+"
> > > shows they are identical. Why? I expected that each bisect would
> lead
> > > to a different kernel.
> > > Assuming that the opposite can happen, does it mean that when I
> say
> > > i.e. "git bisect bad", then build a new kernel and see that is
> > > identical to the previous one I can run "git bisect bad" without
> > > booting into the new one and even making the test?
> > >
> > > Another thing I don't understand is that I told 4.20.0 to be
> good, so
> > > I would expect that I don't need to test any older version, but
> as far
> > > as I know 4.19.0-rc5+ is older than 4.20.0, so why is it
> involved in
> > > the bisection?
> > >
> > > I had to "git bisect skip" one time (the kernel did not boot),
> but as
> > > far as I know I don't think this could be related to my doubts.
> > > [...]
> > 
> > Update:
> >   I have concluded the bisection, found that
> > "9cb5f4873b993497d462b9406f9a1d8a148e461b is the first bad
> commit",
> > reverted it, and the test still fails (btw, the final kernel file,
> > /boot/vmlinuz-4.19.0-rc5+, does not differ from the previous one).
> > 
> > So, all my doubts above are still there (and growing). What I am
> doing wrong?
> 
> Are you _SURE_ that a 4.20.0 release actually worked properly for
> you?
> Did you build one and do your tests?  Or are you just relying on
> your
> Fedora build still?

Yes, I am really sure of that, and the definitive proof is that since
I stopped bisecting I made the 4.20.0 the default boot kernel, and all
my backups are done "quickly" (12min to create a 12GB archive).
Furthermore, "uname -a" shows

Linux 4.20.0 #1 SMP Thu Jun 6 22:32:29 CEST 2019 x86_64 x86_64 x86_64
GNU/Linux

To have one more evidence, I started the test while writing down this
sentence, and it has just finished in one minute and a half (1 GB file
copy).

I will go on following your other suggestions; by the time, thank you
for pointing this out,

Andrea