Re: Defragging XFS File Systems

From: Stan Hoeppner <stan@hardwarefreak.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: Kenneth Emerson <kenneth.emerson@gmail.com>, xfs@oss.sgi.com
Subject: Re: Defragging XFS File Systems
Date: Thu, 09 Jun 2011 13:24:31 -0500	[thread overview]
Message-ID: <4DF10FDF.1090508@hardwarefreak.com> (raw)
In-Reply-To: <201106091212.36227@zmi.at>

On 6/9/2011 5:12 AM, Michael Monnerie wrote:
> 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", 

I tried allocsize=1m but it didn't seem to help already existing files.
 I simply don't think there's much that can be done in filesystem logic
to keep long lived constantly appended files from fragmenting, short of
the log rotation method, which isn't really suitable for large mbox
files.  Maildir is obviously an option to combat fragmentation, but it
has downsides as well, mainly much higher small file IOPS during normal
operation.  Using mbox I can 'hide the IO' by running xfs_fsr at night
and/or on weekends.

> 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.

My current method seems to work well for now.  This filesystem will
likely not even be half full by the time this server is replaced in a
few years, so I probably don't need to worry about xfs_fsr efficiency
WRT free space.  Due to the low cost of today's gargantuan platters, I'm
guessing there are likely many admins in a similar position.  Four 600GB
SAS drives in RAID10 yields ~1.2TB of mail storage.  That's a lot of
space, and performance, for small/medium organization's mailboxes...

-- 
Stan

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs