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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/2020 09:54, Andrea Vai wrote:
> Il giorno gio, 30/05/2019 alle 15.22 +0200, Andrea Vai ha scritto:

[...]

Hi 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]).

OK, good to know and thanks a lot for this detailed feedback!

> 
> 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?

difficult to know for now, but I suspect the difference comes from the
fact cp performs a sequential reading while dar by default reads the
catalog at the end of the archive then skip back near the beginning of
the archive then from time to time skips over the sequential marks
that are used only when reading an archive in sequence.

To confirm this hypothesis, you would retry testing the same archive
with the --sequential-read option.


> 
> 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
> 
> 
> 

Best Regards,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl4gVOkACgkQCDGwvQPY
sYLuTw//dEe0wTepfQgO6VvkJ3yQ2wpfgWP2/+Nlo//CcLMomN+cV+ypCl6maLxz
A4MSuAErT92T3W4zB44nVSHo7ENcr2hLX1wCuXpvrkTLY0eRRx1N+RSs/w7HLeBI
aV0lQbJlLYf2NDLI6UQ9DblFSlVH09299uDPP/uS3Gr1+VmB08eQfaneunfq7yUb
cPJ39h3Zg7HvUAxOcBlm6h8bPmniVPzwFDJkqDl4Kjg4UOoScTeBwHluKmJft2Mb
afmDW4ISQ6IPRor3OnJbpVN6dpCv/2qTsYrUfO4kTUel6yg0yntJEYVTR4MbyEBn
QxuX+dvVtGg/7JRwVaX64NX56VkNSP7BCmhvB/Ht9y9dHVn1ufAkf6jnGDEnxEbo
1htxQU28jOijqNQ6WZpT5BOs+bpAXNJ9Vc7D9r5d+WU18wcEMg2/bdiKjozLy7kv
JDlx4kf+xpvCGpzsABzEFngSPUS17P6bZy87UkPfBh+hBoGuVJFVAP63ymHOOfsd
E4rBVFWHTa8KZDEjZ5kigZwTlT5EGD8AQNsM+W6+GctbPd/SwpNy9qjYZ592PuXa
UqNPFCND93fe7DLjOy+q01Kdl5l5sd9L+Oj58kWwEDa/eK8CCgKcRQ+YF6cxkOrM
PcEmiHhQJWDLASRKszzjbthkuDYu/eDCx9/CLkXrRYcBY9kFeDA=
=IF31
-----END PGP SIGNATURE-----