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

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


On 09/05/2019 08:59, Andrea Vai wrote:
> Il giorno mer, 08/05/2019 alle 09.08 +0100, Neil Darlow via Dar- 
> support ha scritto:
>> Hi Andrea,

[...]

Hello Andrea,

> 
> Hi Neil, thank you very much for this further explanation. I use
> Fedora, so yes, indeed, it's reasonable that I had installed an
> updated kernel across the time the problem rose. I will try to use
> a previous kernel and let you know here.
> 
> By the way, just to add a bit more speculation: if it were a
> kernel related problem, then I'd also have problems with a mere
> file copy, wouldn't I? On the other hand, if it were a usb related
> problem, then I wouldn't have problems with SATA to SATA backup.
> (Where) am I wrong if I assume that those two things leads to
> suspect a problem (at least) in dar itself?

All is possible, but to solve a problem we must first follow the path
leading to most probable cause, eliminating them one by one from the
most to the least probable one, up to the time we find an explanation
and a coherent behavior with that explanation so we can fix and be
sure the problem is fixed.

Here dar cannot by itslef decide to stay in uninterrupted sleep: this
is the kernel decision to put processes in that state when it is
treating the request he received from that process - network, disk,
whatever.  Second you did not mentioned having changed of dar version
since the last backup while all was working good, so why should this
behavior be caused by dar while it was working fine in the past? ...
this seems less probable than an I/O problem as suggested by Neil.

Now there is something weird I agree, dar is put in the D state when
it is releasing memory (at that time all disk I/O have completed and
even if data is still in the cache, pending from writing to disk, dar
is not concerned by that). This points rather toward a memory (RAM)
problem or a memory management problem, or a swap problem like
corruption of the swap file/partition or a disk problem where the swap
is stored...

Usually RAM problem does corrupt data, the kernel returns immediately
but the wrong data. You can still check your RAM using memtest86+ (the
best way I know for that is relying on system rescueCD which has a
boot mode to do that easily - http://www.system-rescue-cd.org/ )

Remains the swap which is to me the most probable cause. I would do
the following:

First disabling the swap:
# swapoff -a

grab the UUID of the swap partition(s) using /sbin/blkid as root
program which is available in the util-linux package (if using Debian
or child distro):

# blkid

then recreate the swap partition preserving its original UUID (to
avoid having to modify /etc/fstab with a new UUID)

# mkswap -c -U <UUID> /dev/sdXY

where <UUID> is the UUID reported by blkid for your /dev/sdXY swap
partition

Then reactive the swap partition(s)

# swapon -a


Anyway, whatever is asked to the kernel (by mean of system call) if it
is "bad", it should fail immediately, dar would report an error, or
would be crashed by the system (core dump), or would do ugly things
looping and consuming a lot of CPU in vain, ... but it would not be
waiting for the kernel to answer the request it made (which is such D
state)


> 
> Thank you, Andrea
> 
> 
> 

Regards,
Denis

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAlzT8ZcACgkQCDGwvQPY
sYLF9RAApdZjycGa4qYWzdHFxtZBHb7T+jvZRYo5fLhJtUBbhWQQE1DOiPnfwvyT
O8BswW361NIHYdr4au5RrjFrYRj75IMzWZL39WzanQq60/pLJTKwJXZrLkCHbf7w
eLVA2f4/NFqq35nMK2XmBQgqDo5VyzEmKepKfgd2UZcJK2dql7/DxWOIsTKx/y8J
yf9be7XOXKVSx4Egkh5i3X4z5WBTw+kGzl3aXFnGVbdo/s18RoL0x2ViupYaWf8W
W1QpjeQavSShwmQ4chOA1o2F6nsdJWP8B+6xZYLLXfMOxFo42mVY3jCUxiGC8kq7
YjPexpEfaywBkJk/Lv4Q3VVs5HR5D/omxBsjWU7StgeFSDG2DZ6M72g8O/7HxjI/
glXWOVrB2l7ROs87F/eoSkCUsDxfgDhNcRwTP8qG98kNKEsA/69Ku3oCAFz0U+s3
flwUwvJ11FlRLqVWZZB1C2B39aSiU5BBzn74HuEmNeB4w5DG1zt403Tmlr2GzhSI
SmC+gFJIiqdgtqu+SQDOw14He7LnkyKke/W410tZmHhCwWQsNGtbm2xhTM4YMuqO
vOF5/zucBAKxFuT2O+TPbVAR8P8u2PqN/hH2ChIpWBjBKaayFX4+HopCX+5mLExl
N3YWfkPPseZeOhVykEt8gN7ZoIaL9mMEmwiw+9W4CNEcfNdC5V8=
=g6ij
-----END PGP SIGNATURE-----