public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS for lots of small files
Date: Sun, 25 May 2008 10:39:37 -0500	[thread overview]
Message-ID: <48398839.6060304@sandeen.net> (raw)
In-Reply-To: <200805251338.48910.Martin@lichtvoll.de>

Martin Steigerwald wrote:
> Am Sonntag 25 Mai 2008 schrieb Eric Sandeen:
>> Martin Steigerwald wrote:
>>> And there is quite some fragmentation on it:
>>>
>>> xfs_db> frag
>>> actual 653519, ideal 587066, fragmentation factor 10.17%
>> No, there's not.
> 
> OK, so there is or better was (see below) *some* fragmentation.
> 
>> You have 653519 extents out of an "ideal" 587066.
>>
>> That is 653519/587066 = 1.113 extents per file.
>>
>> It is not "quite some" fragmentation, it is near perfect (although this
>> is subjective, and also depends on the size of your files... if they
>> are all 8k then 1.113 extents per file might be a bit high; if they
>> average 1G then 1.113 extents on average is pretty darned good.)
> 
> They vary a lot. From KMail ~/Mail directory with hundred of thousands of 
> mails in maildir format to a picture and movie collection from various 
> digicams with 150KB over 2-4 MB to 50-200 MB in size and a music 
> collection and kernel sources and and and... would need to run a tool on 
> them to gather some statistic.
> 
> Anyway, nothing that can't be optimized:

Sure... I'd just argue that it's diminishing returns :)

> shambala> xfs_db -r /dev/sda5
> xfs_db> frag
> actual 683648, ideal 617593, fragmentation factor 9.66%
> xfs_db> quit
> 
> shambala> xfs_fsr /dev/sda5
> /home start inode=0
> 
> shambala> xfs_db -r /dev/sda5
> xfs_db> frag
> actual 620316, ideal 617584, fragmentation factor 0.44%
> xfs_db> quit
> 
> xfs_fsr copied over several gigabytes and the free space of the partition 
> temporarily more than once was 4 GB less than the 20 GB of free space it 
> had before and after invoking xfs_fsr ;)

fsr needs to preallocate space to "defragment into" so this is expected,
temporarily.

> Not that I noticed a difference up to now however.

right, my original reply was meant to imply that fragmentation is not
really a problem for you.  :)

And in the larger picture, I just wanted to point out that the
"fragmentation factor" can be pretty misleading.  It reports as (actual
- ideal) / actual.

Imagine a filesystem full of 8GB dvd iso images, each with 4 2GB
extents.  The fragmentation factor would be reported as (4X - 1X) / 4X =
75%.  Which looks "bad," but really isn't.

-Eric

      reply	other threads:[~2008-05-25 15:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-06 16:11 XFS for lots of small files Leszek Dubiel
2008-05-06 16:23 ` Nicolas KOWALSKI
2008-05-06 18:55 ` Martin Steigerwald
2008-05-23  0:44   ` Linda Walsh
2008-05-24 16:16     ` Martin Steigerwald
2008-05-25  3:25   ` Eric Sandeen
2008-05-25 11:38     ` Martin Steigerwald
2008-05-25 15:39       ` Eric Sandeen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48398839.6060304@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=Martin@lichtvoll.de \
    --cc=linux-xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox