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

Hi,
  I have a dar differential backup set up as a cronjob and it had
always worked fine until some days ago, when dar began to take many
time to complete. So I tried running the same command from the command
line, and I see that after the backup completes (prompt returns in the
terminal, and -v (verbose) does not show anything strange):...

Closing archive low layer...
Archive is closed.


 --------------------------------------------
 134605 inode(s) saved
   including 47628 hard link(s) treated
 0 inode(s) changed at the moment of the backup and could not be saved
properly
 0 byte(s) have been wasted in the archive to resave changing files
 1395750 inode(s) not saved (no inode/file change)
 0 inode(s) failed to be saved (filesystem error)
 21 inode(s) ignored (excluded by filters)
 1656 inode(s) recorded as deleted from reference backup
 --------------------------------------------
 Total number of inode(s) considered: 1532032
 FSA saved for 0 inode(s)
 --------------------------------------------
Making room in memory (releasing memory used by archive of
reference)...
Final memory cleanup...


...the process is still present in the output of "ps aux":

root      7088  5.8 12.4 3173300 3022044 ?     D    10:30   2:45 dar -c /run/media/andrea/BAK_ANDVAI/Diff_MezzOre -R / -B /home/andrea/MyProgs/Backup/esclusi.dcf -D -A /home/andrea/Backup/CAT_Normal -w -v

Furthermore, the process appears in D state, which in turns seems to
be related to IO latency (?), and I cannot kill it in any way.

If I wait some time (MANY time, say 1 hour, despite the backup time is
some minutes), the process terminates and I can't note anything
strange.

dmesg also doesn't show any I/O error.
Of course, I didn't change any option/config files in the dar command.

UPDATE: I have done some more testing and a differential backup that
usually completes in 10-15 minutes now takes more than one hour. Now I
am running a full backup, as I do monthly: it usually completes in a
couple of hours, and I can estimate that now it would take 2 days (!)
to complete.

While performing the full backup (right now, while I am composing this
message), "ps aux |grep dar" shows

root     20710  0.0  0.0 122276  7392 pts/1    S+   mag07   0:00 sudo time dar -vd -vm -c /run/media/andrea/Backup_Angus/Normal -R / -B /home/andrea/MyProgs/Backup/esclusi.dcf -D -@ /home/andrea/Backup/CAT_Normal
root     20714  0.0  0.0   2180   756 pts/1    S+   mag07   0:00 time dar -vd -vm -c /run/media/andrea/Backup_Angus/Normal -R / -B /home/andrea/MyProgs/Backup/esclusi.dcf -D -@ /home/andrea/Backup/CAT_Normal
root     20715  3.3  3.2 918060 785436 pts/1   D+   mag07  41:45 dar -vd -vm -c /run/media/andrea/Backup_Angus/Normal -R / -B /home/andrea/MyProgs/Backup/esclusi.dcf -D -@ /home/andrea/Backup/CAT_Normal

I didn't notice any other strange behaviour on my system recently.

maybe it can be related to a kernel update?

Is there any other way to investigate it?

$ dar -V

 dar version 2.5.3, Copyright (C) 2002-2052 Denis Corbin
   Long options support       : YES

 Using libdar 5.7.3 built with compilation time options:
   Libz compression (gzip)      : NO
   Libbz2 compression (bzip2)   : NO
   Liblzo2 compression (lzo)    : NO
   Liblzma compression (xz)     : NO
   Strong encryption (libgcrypt): NO
   Public key ciphers (gpgme)   : NO
   Extended Attributes support  : NO
   Large files support (> 2GB)  : YES
   ext2fs NODUMP flag support   : NO
   Special allocation scheme    : YES
   Integer size used            : 64 bits
   Thread safe support          : YES
   Furtive read mode support    : YES
   Linux ext2/3/4 FSA support   : NO
   Mac OS X HFS+ FSA support    : NO
   Detected system/CPU endian   : little
   Posix fadvise support        : YES
   Large dir. speed optimi.     : YES
   Timestamp read accuracy      : 1 microsecond
   Timestamp write accuracy     : 1 microsecond
   Restores dates of symlinks   : YES

 compiled the Apr 27 2016 with GNUC version 5.3.1 20160406 (Red Hat 5.3.1-6)

I run dar on a Fedora 29 system (recently updated from F28, where the
problem was firstly encountered) with 24GB RAM.

Thank you very much in advance for your help,

Bye
Andrea