All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.