linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Hugo Mills <hugo@carfax.org.uk>,
	"BTRFS, Linux" <linux-btrfs@vger.kernel.org>
Cc: Calvin Walton <calvin.walton@kepstin.ca>
Subject: Re: Does defragmenting even work
Date: Thu, 28 Feb 2013 16:16:44 +0100	[thread overview]
Message-ID: <512F74DC.8050404@petaramesh.org> (raw)
In-Reply-To: <20130228150044.GN14283@carfax.org.uk>

Thanks Hugo, ans thanks Calvin for your clear explanations.

I actually use compression on all of my FSes, and I have seen that
"filefrag -v" reports different "physical" and "expected" values for
many files, meaning of which I didn't understand at all.

This said, I now assume that my current script approach "check with
filefrag it the file presents any (apparent) fragmentation, if yes run
defrag on it" may be good enough, or would it be more efficient to
directly run defrag on all files without bothering checking it they
(may) be fragmented or not (which boils down to : "which of filefrag or
btrfs defrag runs faster ?") ?

Also, does "btrfs filesystem defrag" does anything smart for
defragmenting free space, or does it only care about defragmenting the
file it was asked to process ?

Anyway I hope to recover "brand new-like" performance after having
removed all snapshots and defragged everything...

Remains the issue of the open files, I'm not sure if it's worth trying
to defragment them with the system running from a live USB stick or so...?

Kind regards.

Le 28/02/2013 16:00, Hugo Mills a écrit :
> If you have a compressed file, each compression block (128k of
> compressed data, if I remember rightly) will show up as a separate
> fragment, even if it's contiguous with the others -- it's an artefact
> of the way that fiemap/filefrag calculates fragments, and the way that
> btrfs reports compressed files. Also, on a full filesystem, complete
> defragmentation may not be completely possible. Similarly, very large
> files may not be easy or possible to defragment fully -- a 2GB file
> with four fragments isn't exactly a problem, for example. Hugo. 


-- 
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
Ne cherchez pas : Je ne suis pas sur Facebook.


  reply	other threads:[~2013-02-28 15:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-28 14:35 Does defragmenting even work Swâmi Petaramesh
2013-02-28 14:44 ` cwillu
2013-02-28 15:00 ` Calvin Walton
2013-02-28 15:00 ` Hugo Mills
2013-02-28 15:16   ` Swâmi Petaramesh [this message]
2013-02-28 15:35 ` Martin Steigerwald

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=512F74DC.8050404@petaramesh.org \
    --to=swami@petaramesh.org \
    --cc=calvin.walton@kepstin.ca \
    --cc=hugo@carfax.org.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).