xfs
[Top] [All Lists]

Re: Defragging XFS File Systems

To: xfs@xxxxxxxxxxx
Subject: Re: Defragging XFS File Systems
From: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 9 Jun 2011 12:12:35 +0200
Cc: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>, Kenneth Emerson <kenneth.emerson@xxxxxxxxx>
In-reply-to: <4DF080AC.2090507@xxxxxxxxxxxxxxxxx>
Organization: it-management http://it-management.at
References: <BANLkTi=40mmE+DCbLcSWBwNQtWpP=N=tXw@xxxxxxxxxxxxxx> <201106090749.37745@xxxxxx> <4DF080AC.2090507@xxxxxxxxxxxxxxxxx>
User-agent: KMail/1.13.6 (Linux/2.6.38.6-zmi; KDE/4.6.0; x86_64; ; )
On Donnerstag, 9. Juni 2011 Stan Hoeppner wrote:
> When is running xfs_fsr recommended?

Good question. One case that comes to my mind is a filesystem that was 
used a long time when filled >85%, which has now either been expanded or 
files removed so you have a lot of space again, and you want to defrag 
all those files that have been badly fragmented.
 
> I scheduled it twice a week some time ago due to a filesystem
> containing active mbox files.  I did so because they became so
> heavily fragmented in short order, especially those swallowing
> copious amounts of list mail.  Before cron'ing xfs_fsr I was seeing
> mbox files with over 1000 fragmented extents, and increasing MUA
> latency as the files became more fragmented.  The filesystem is
> currently 90% free.

This is also an example where defrag may help. You have 10% usage, so 
there's enough space. Maybe your usage fits the mount option 
"allocsize", so that you keep room for file append. But newer kernels 
changed behaviour of XFS, so I'm not sure up to which kernel version its 
good. Maybe Dave Chinner can chime in here. BTW, maybe this behaviour 
should be documented in the FAQ so we can reference it.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

Attachment: signature.asc
Description: This is a digitally signed message part.

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