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

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



On 17/01/2020 12:47, Andrea Vai wrote:
[...]
> 
> I have just tried and didn't make any difference, but I am
> wondering whether I am not understanding something. My problem
> appears while writing a new archive, so does --sequential-read
> option matter as well in that case?

Yes, you are correct. The sequential-read does nothing (except
concerning the archive of reference if used) when creating an archive.

The archive is produced by appending data to a file, there still might
be some seek backward if compression is worse than storing data
uncompressed (operation cp does not do). This one is not possible to
disable unless you disable compression at all. You can also write the
archive to stdout to avoid having this occuring though dar will try
and get an error so the system call will still differ from what cp
would do.

	dar -c - .... > my.archive.1.dar

Another condition that have influence on the way dar writes to an
archive is when a file has changed, dar will retry saving it up to 3
times by default. See --retry-on-change option to disable this.


> 
> the command I run is
> 
> # SECONDS=0; mount UUID=ae7ac0ca-d0bc-46c8-81f1-d2b67e1f95f3
> /mnt/pendrive && rm -f /mnt/pendrive/aero.1.dar && dar -c
> /mnt/pendrive/aero -R /home/andrea/Musica/MP3/Aerosmith && umount
> /mnt/pendrive; echo "Ci ho messo: $SECONDS secondi.
> 
> which, as far as I know, doesn't involve reading a catalog, does
> it?

You seems doing a full backup (I cannot see whether there is a .darrc
or /etc/darrc but assuming there is none) without compression on data
that do not seem subject to change. So I thus cannot see what dar does
so differently from the cp command in that context for the first
trigger the kernel bug while the second does not...

> 
> Thanks, and bye Andrea
> 

Cheers,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl4iGdkACgkQCDGwvQPY
sYIqnRAAp7pXcPcCUdjiAB+DeXMTyQEdA3/krQmq9SzFXsDfiMHGVjhNamY/1lU7
oYDpQ7XVRjzwpWutKSryrFKt6M2kWXOTxLAZe3iamjn79bs6YhCTgAdZ0y+abi00
QFbftcOuw03T/TMTr7c5yC73xKqQx3l0YOU6GxQmZdLyXpTyLUBFWGjieklCXwLp
0GP79GG1Y/3elrD69lRXoLeYb0OMHxRBUkouo1WVzKKSXAbtiivB+BAa2nFB1gez
Pgx7pxye5+QmnmPdYstV4E8ynm/MbFjO59UT4Ta1sGFoh24bEPGQWCoZKxfLaLev
VmxVNCSmKkqjPNxEq0sIPYUOaJvzvDvqNVHhIqna/FuBT6BY3wh7RFwoYuXUFxtt
Sgs0vyu166WvwNKkX8fCgvr95Hwp20ytyOM+NX/t0O/hRqHSmpw5fezKybfL27Bg
T4oa9wmGDu4ZjmXouLS4TFw7CbVUTRZBSv+kwKIoA21sjJ+vI12+Z5dB/bs6fpsh
xB4pqT2PdSLKCe9aSQVlVrSyAAK+M0fMNvtkGcucyfeG+w8Hdhs5PGENSn9XObZI
MPI9jFkFT4tIF6Be4TFtS2Hhc4ljERO/tXUb44Rl6Q7+4ij4BKlZaRa+qhX8KZET
81o6y+jIpqkk2IMrRGT1c6qYjsgEm3ZlZUwh1NomodKeaT7RRaU=
=1K3f
-----END PGP SIGNATURE-----