extremely slow file creation/deletion after xfs ran full

[Carsten Aulbert]

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.

Cheers

Carsten


-------------- next part --------------
A non-text attachment was scrubbed...
Name: touch.stack.gz
Type: application/gzip
Size: 3498 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20150112/8dc6101a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rm.stack.gz
Type: application/gzip
Size: 702 bytes
Desc: not available
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20150112/8dc6101a/attachment-0001.bin>