From: Liu Bo <bo.li.liu@oracle.com>
To: Sebastian Ochmann <ochmann@informatik.uni-bonn.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Why does btrfs defrag work worse than making a copy of a file?
Date: Thu, 17 Jul 2014 11:36:46 +0800 [thread overview]
Message-ID: <20140717033645.GA2290@localhost.localdomain> (raw)
In-Reply-To: <53C658F6.1070301@informatik.uni-bonn.de>
On Wed, Jul 16, 2014 at 12:50:30PM +0200, Sebastian Ochmann wrote:
> 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.
Oops, we've deeply made users confused in this old documents, will update it
then.
thanks,
-liubo
>
> 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
prev parent reply other threads:[~2014-07-17 3:37 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
2014-07-17 3:36 ` Liu Bo [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=20140717033645.GA2290@localhost.localdomain \
--to=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=ochmann@informatik.uni-bonn.de \
/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.