I am running rawhide. When I do a dnf update, it goes at normal speed, but the verify step takes a long time. I had an update of 789 MB, and it took ~ 30 minutes to verify. A 123 MB kernel install took between 10 and 15 minutes to verify. During these verify proceedings, dnf is writing constantly to the disk (seen with iotop). No reads, all writes. That seems strange.
Is this expected behavior? Can anyone explain why dnf is doing all those writes after the update has completed?
Thanks.
On Sun, 11 Jul 2021 12:50:56 -0700 stan upaitag@zoho.com wrote:
I am running rawhide. When I do a dnf update, it goes at normal speed, but the verify step takes a long time. I had an update of 789 MB, and it took ~ 30 minutes to verify. A 123 MB kernel install took between 10 and 15 minutes to verify. During these verify proceedings, dnf is writing constantly to the disk (seen with iotop). No reads, all writes. That seems strange.
Is this expected behavior? Can anyone explain why dnf is doing all those writes after the update has completed?
This is no longer happening. Waited several days to be sure, but gone.
On Tue, Jul 27, 2021 at 9:00 AM stan via test test@lists.fedoraproject.org wrote:
On Sun, 11 Jul 2021 12:50:56 -0700 stan upaitag@zoho.com wrote:
I am running rawhide. When I do a dnf update, it goes at normal speed, but the verify step takes a long time. I had an update of 789 MB, and it took ~ 30 minutes to verify. A 123 MB kernel install took between 10 and 15 minutes to verify. During these verify proceedings, dnf is writing constantly to the disk (seen with iotop). No reads, all writes. That seems strange.
Is this expected behavior? Can anyone explain why dnf is doing all those writes after the update has completed?
This is no longer happening. Waited several days to be sure, but gone.
I'd expect verify to be mostly reads.
A strace of dnf might reveal what it's up to. A sysrq+t would show what everyone is doing including if there's anything else especially busy that's maybe slowing down whatever dnf is up to. It's sufficiently verbose that it will fill up the kernel message buffer, and likely a lot of messages will be dropped, so use journalctl -k rather than dmesg to collect the output from a sysrq+t.
-
Chris Murphy -
stan