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