[Top] [All Lists]

Re: extremely slow file creation/deletion after xfs ran full

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: extremely slow file creation/deletion after xfs ran full
From: Carsten Aulbert <Carsten.Aulbert@xxxxxxxxxx>
Date: Mon, 12 Jan 2015 17:09:01 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150112155206.GD25944@xxxxxxxxxxxxxxx>
Organization: Max Planck Institute for Gravitational Physics - Albert Einstein Institute (AEI)
References: <54B387A1.6000807@xxxxxxxxxx> <54B3CC6A.4080405@xxxxxxxxxx> <20150112155206.GD25944@xxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0
Hi Brian

On 01/12/2015 04:52 PM, Brian Foster wrote:
> I can't see any symbols associated with the perf output. I suspect
> because I'm not running on your kernel. It might be better to run 'perf
> report -g' and copy/paste the stack trace for some of the larger
> consumers.

Sorry, I rarely need to use perf and of course forgot that the
intermediate output it tightly coupled to the running kernel. Attaching
the output of perf report -g here.
> Sounds good. FWIW, something like the following should tell us how many
> free inodes are available in each ag, and thus whether we have to search
> for free inodes in existing records rather than allocate new ones:
> for i in $(seq 0 15); do
>       xfs_db -c "agi $i" -c "p freecount" <dev>
> done
Another metric :)

freecount = 53795884
freecount = 251
freecount = 45
freecount = 381
freecount = 11009
freecount = 6748
freecount = 663
freecount = 595
freecount = 693
freecount = 9089
freecount = 37122
freecount = 2657
freecount = 60497
freecount = 1790275
freecount = 54544

That looks... not really uniform to me.



Attachment: touch.stack.gz
Description: application/gzip

Attachment: rm.stack.gz
Description: application/gzip

<Prev in Thread] Current Thread [Next in Thread>