xfs
[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: extremely slow file creation/deletion after xfs ran full
From: Carsten Aulbert <Carsten.Aulbert@xxxxxxxxxx>
Date: Wed, 14 Jan 2015 07:12:55 +0100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150113203332.GD29484@destitution>
Organization: Max Planck Institute for Gravitational Physics - Albert Einstein Institute (AEI)
References: <54B387A1.6000807@xxxxxxxxxx> <54B3CC6A.4080405@xxxxxxxxxx> <20150112155206.GD25944@xxxxxxxxxxxxxxx> <54B3F19D.6030307@xxxxxxxxxx> <20150112163749.GE25944@xxxxxxxxxxxxxxx> <54B40552.50106@xxxxxxxxxx> <20150113203332.GD29484@destitution>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0
Hi Dave

On 01/13/2015 09:33 PM, Dave Chinner wrote:
> 
> This pattern seems to match a filesystem that was running under
> inode32 for most of it's life, and is now using inode64 and hence
> spreading the subdirectories and hence new inodes over all AGs
> instead of just limiting them to AG 0....
> 

I fear you are right. The install logs from 2012 show, that fstab simply
contained:

UUID=dd407af5-1edc-41de-8c72-5fe1de31fb11 /srv xfs rw  0 2

And our change management is not that good to track back, when we
changed to inode64.

OK, I think I've gathered quite a lot of things we did wrong. I'll try
to summarize it in another email later today or tomorrow to invite a few
more comments before we go ahead redoing the FS. Also, it may serve as
summary for the list archive.

For now, I want to say a very, very big thank you for remarks and
suggestions!

Cheers

Carsten

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