linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Ochmann <ochmann@informatik.uni-bonn.de>
To: bo.li.liu@oracle.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Why does btrfs defrag work worse than making a copy of a file?
Date: Wed, 16 Jul 2014 12:50:30 +0200	[thread overview]
Message-ID: <53C658F6.1070301@informatik.uni-bonn.de> (raw)
In-Reply-To: <20140716075345.GB29931@localhost.localdomain>

On 16.07.2014 09:53, Liu Bo wrote:
> On Tue, Jul 15, 2014 at 11:17:26PM +0200, Sebastian Ochmann wrote:
>> Hello,
>>
>> I have a VirtualBox hard drive image which is quite fragmented even
>> after very light use; it is 1.6 GB in size and has around 5000
>> fragments (I'm using "filefrag" to determine the number of
>> fragments). Doing a "btrfs fi defrag -f image.vdi" reduced the
>> number of fragments to 3749. Even doing a "btrfs fi defrag -f -t 1
>> image.vdi" which should make sure every extent is rewritten
>> (according to the btrfs-progs 3.14.2 manpage) does not yield any
>> better result and seems to return immediately. Copying the file,
>> however, yields a copy which has only 5 fragments (simply doing a cp
>> image.vdi image2.vdi; sync; filefrag image2.vdi).
>>
>> What do I have to do to defrag the file to the minimal number of
>> fragments possible? Am I missing something?
>
> So usually btrfs thinks of an extent whose size is bigger than 256K as a big
> enough extent.
>
> Another possible reason is that there is something wrong with btrfs_fiemap which
> gives filefrag' a wrong output.
>
> Would you please show us the 'filefrag -v' output?

Sure, I have pasted the output of "filefrag -v" here:

http://pastebin.com/kcZhVhkc

However, I think the problem is merely in the documentation (manpage of 
btrfs-filesystem). The description of the "-t" option is different in 
two locations and doesn't make sense in general, I think. It is first 
described as follows:

"Any extent bigger than threshold given by -t option, will be considered 
already defragged. Use 0 to take the kernel default, and use 1 to say 
every single extent must be rewritten."

So I used "-t 1" because I thought it will defrag as much as possible. 
However when thinking about it, any extent at least 1 byte (or 2 bytes?) 
in size will be ignored this way, am I correct?

Further below, the "-t" option is described as follows:

"-t <size>  defragment only files at least <size> bytes big"

Here, the option suddenly refers to the file size. In any case, doing a 
"btrfs fi defrag -f -t 10G image.vdi" defragged my file to the 5 extents 
I also get by simply copying the file. I think the documentation should 
be updated to reflect what the -t option actually does.

Best regards
Sebastian


> thanks,
> -liubo
>
>>
>> Kernel version 3.15.5, btrfs progs 3.14.2, Arch Linux.
>>
>> Best regards,
>> Sebastian
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-07-16 10:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-15 21:17 Why does btrfs defrag work worse than making a copy of a file? Sebastian Ochmann
2014-07-16  7:53 ` Liu Bo
2014-07-16 10:50   ` Sebastian Ochmann [this message]
2014-07-17  3:36     ` Liu Bo

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=53C658F6.1070301@informatik.uni-bonn.de \
    --to=ochmann@informatik.uni-bonn.de \
    --cc=bo.li.liu@oracle.com \
    --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).