Re: dar became very slow (and process in D state?)

Andrea Vai <[email protected]>
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
Il giorno gio, 30/05/2019 alle 15.22 +0200, Andrea Vai ha scritto:
> Hi,
>   Il giorno gio, 30/05/2019 alle 08.59 +0200, Andrea Vai ha scritto:
> > Hi,
> > Il giorno mar, 21/05/2019 alle 18.51 +0200, Denis Corbin ha
> scritto:
> > > [...]
> > > 
> > > OK, as this is not dar specific and as this is kernel dependent,
> > at
> > > this stage of investigation we will wait for the feedback from
> > > kernel
> > > side, though, this thread is not closed...
> > 
> > As I still haven't had any answer from [1], I also filed a bug
> > against
> > the linux-kernel here:
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=203757
> 
> And they told me to write on the kernel mailing list, for anyone
> interested located at:
> 
> https://marc.info/?l=linux-usb&m=155922230126819&w=2
> 
> Bye,
> Andrea

Hi,
  after some (many) months of research and test, the kernel dev's
found the problem was introduced by a kernel patch, which affects
apparently some "low quality" device only. We don't know if the kernel
will be updated to make again these kind of devices be "fast", but the
latest news are that the topic will be submitted to the coming LSFMM
2020, so that more people may pay attention to it.

For anyone interested, the full story is available at two threads in
the kernel mailing lists (starting at [1], and then [2]).

At the time of writing, I have workarounded the problem by using an
ssd drive instead of the "low quality" pendrive. In fact, it seems
that ssd drives are not affected by the problem (details are in the
kernel discussion threads linked below).

I hope all of this could help anyone with the same problem in the
future.

On the dar side, there's another detail I would like to further
investigate: I used to test the problem by running a "cp" command
which clearly shows a difference in time with the old kernel vs. new
kernel. We found a way to workaround the problem by removing the
destination file before the begin of the file copy, but this
workaround does not work if I use dar instead of cp: if I remove the
old archive before starting the new dar command, the operation is stil
"slow". Could anyone (Denis?) explain this behavior or say whether it
makes sense in the current scenario?

Thanks, and bye
Andrea

[1]: https://marc.info/?l=linux-usb&m=155922230126819&w=2
[2]: https://marc.info/?l=linux-usb&m=156206441516201&w=2
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.