All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc MERLIN <marc@merlins.org>
To: Chris Mason <clm@fb.com>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: counting fragments takes more time than defragmenting
Date: Tue, 23 Jun 2015 20:20:08 -0700	[thread overview]
Message-ID: <20150624032008.GF20517@merlins.org> (raw)
In-Reply-To: <20150604084245.GR23272@merlins.org>

Hello again,

Just curious, is anyone seeing similar things with big VM images or other
DBs?
I forgot to mention that my vdi file is 88GB.

It's surprising that it took longer to count the fragments than to actually
defragment the file.
Or that it took 3 defrag runs to get down to 11K extents from 104K.

Are others seeing similar things?

Marc

On Thu, Jun 04, 2015 at 05:42:45PM +0900, Marc MERLIN wrote:
> Hi Chris,
> 
> After our quick chat, I gave it a shot on 3.19.6, and things are better
> than last time I tried.
> 
> legolas:/var/local/nobck/VirtualBox VMs# lsattr Win7/
> ---------------C Win7/Logs
> ---------------C Win7/Snapshots
> ---------------C Win7/Win7.vdi
> ---------------C Win7/Win7.png
> ---------------C Win7/autotune1.png
> ---------------C Win7/new_autotune2.png
> ---------------C Win7/Win7.vbox-prev
> ---------------C Win7/Win7.vbox
> 
> But I have snapshots of that subvolume, so obviously that gets
> in the way of disabling COW.
> 
> I had a look, and I have 100K fragments. That took 10mn to figure out:
> 
> legolas:/var/local/nobck/VirtualBox VMs/Win7# filefrag Win7.vdi
> Win7.vdi: 104306 extents found
> 
> This first filefrag run took about 10mn to count all the fragments on my
> SSD. That feels a bit slow, but maybe the userland tool is doing things
> in suboptimal ways.
> 
> Defrag actually worked (mostly) and wasn't too slow. It used to take hours
> not to finish, and now it worked in 3mn:
> legolas:/var/local/nobck/VirtualBox VMs/Win7# time btrfs fi defrag Win7.vdi 
> real	3m43.807s
> user	0m0.000s
> sys	0m44.044s
> 
> This is defintely better than before.
> Note that it's not fully defragged, but close enough. Each subsequent
> run, filefrag is faster, and defrag is still faster than filefrag:
> 
> legolas:/var/local/nobck/VirtualBox VMs/Win7# time filefrag Win7.vdi
> Win7.vdi: 11428 extents found
> real	2m42.090s
> user	0m0.000s
> sys	2m37.308s
> 
> legolas:/var/local/nobck/VirtualBox VMs/Win7# time btrfs fi defrag Win7.vdi 
> real	0m7.483s
> user	0m0.000s
> sys	0m2.672s
> 
> legolas:/var/local/nobck/VirtualBox VMs/Win7# time filefrag Win7.vdi
> Win7.vdi: 11132 extents found
> real	0m22.525s
> user	0m0.000s
> sys	0m22.264s
> 
> It's a bit unexpected that I still have 10k fragments after 2 defrag
> runs, but it's better than 100k :)
> 
> Marc
> -- 
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
> Microsoft is to operating systems ....
>                                       .... what McDonalds is to gourmet cooking
> Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901
> --
> 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
> 

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

  reply	other threads:[~2015-06-24  3:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-04  8:42 counting fragments takes more time than defragmenting Marc MERLIN
2015-06-24  3:20 ` Marc MERLIN [this message]
2015-06-24  8:28   ` Patrik Lundquist
2015-06-24 10:46     ` Duncan
2015-06-24 12:05       ` Patrik Lundquist
2015-06-25  4:01         ` Duncan
2015-06-25  6:30           ` Patrik Lundquist
2015-07-14 11:57       ` Patrik Lundquist
2015-07-14 17:32         ` Duncan
2015-07-14 18:41         ` Hugo Mills
2015-07-14 19:09           ` Patrik Lundquist
2015-07-14 19:15             ` Hugo Mills
2015-07-21 15:35               ` Patrik Lundquist

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=20150624032008.GF20517@merlins.org \
    --to=marc@merlins.org \
    --cc=clm@fb.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 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.