https://bugzilla.kernel.org/show_bug.cgi?id=207817 --- Comment #2 from bfoster@xxxxxxxxxx --- On Thu, May 21, 2020 at 04:45:34PM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=207817 > > --- Comment #1 from Alexander Petrovsky (askjuise@xxxxxxxxx) --- > After 1 day, it seems like some internal activity calm down kworker at 00:00 > UTC, it could be logrotate or smth else. But now, I'm observe the follow > (seems > like it has the same root cause): > Note that you're reporting problems with a distro kernel and proprietary hypervisor to an upstream mailing list (via an upstream bug tracker). The feedback will likely be limited unless you can reproduce on an upstream kernel. In general, it's not really clear to me what you're reporting beyond the writeback task using more CPU than anticipated. What is that based on? What problematic functional or performance related behavior is observed? If performance related, what exactly is the workload? > #df -h > Filesystem Size Used Avail Use% Mounted on > ... > /dev/mapper/vg_logs-lv_varlog 38G -30G 68G - /var/log > ... I think we've had some upstream patches to fix underflows and such in space reporting paths fairly recently, but I'm not sure off hand if those are associated with any functional issues beyond indication of potential corruption. This suggests you should probably run 'xfs_repair -n' on this filesystem if you haven't already. Brian > > -- > You are receiving this mail because: > You are watching the assignee of the bug. > -- You are receiving this mail because: You are watching the assignee of the bug.
