On Mon, May 09, 2022 at 10:10:57PM -0700, Darrick J. Wong wrote:
On Tue, May 10, 2022 at 07:07:35AM +0300, Amir Goldstein wrote:
On Mon, May 09, 2022 at 12:46:59PM +1000, Chris Dunlop wrote:
Is it to be expected that removing 29TB of highly reflinked and fragmented
data could take days, the entire time blocking other tasks like "rm" and
"df" on the same filesystem?
...
From a product POV, I think what should have happened here is that
freeing up the space would have taken 10 days in the background, but
otherwise, filesystem should not have been blocking other processes
for long periods of time.
Indeed. Chris, do you happen to have the sysrq-w output handy? I'm
curious if the stall warning backtraces all had xfs_inodegc_flush() in
them, or were there other parts of the system stalling elsewhere too?
50 billion updates is a lot, but there shouldn't be stall warnings.
Sure: https://file.io/25za5BNBlnU8 (6.8M)
Of the 3677 tasks in there, only 38 do NOT show xfs_inodegc_flush().
I bet, however, that you and everyone else would rather have somewhat
inaccurate results than a load average of 4700 and a dead machine.
Yes, that would have been a nicer result.
Chris
