linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* btrfs is slow while looping in search_bitmap <-btrfs_find_space_for_alloc
@ 2017-09-05  5:58 Stefan Priebe - Profihost AG
  2017-09-11  9:23 ` Stefan Priebe - Profihost AG
  0 siblings, 1 reply; 2+ messages in thread
From: Stefan Priebe - Profihost AG @ 2017-09-05  5:58 UTC (permalink / raw)
  To: linux-btrfs@vger.kernel.org

Hello,

while expecting slow btrfs volumes i switched to kernel v4.13 and to
space_cache=v2.

But i'm still expecting slow performance and single kworker processes
using 100% CPU.

Tracing the kworker process shows me:
# sed 's/.*: //' /trace | sort | uniq -c | sort -n
  21595 tree_search_offset.isra.23 <-btrfs_find_space_for_alloc
  21610 btrfs_find_space_for_alloc <-find_free_extent
  21619 _raw_spin_lock <-btrfs_find_space_for_alloc
  27431 _cond_resched <-find_free_extent
  27437 down_read <-find_free_extent
  27451 block_group_cache_done.isra.29 <-find_free_extent
  27451 btrfs_put_block_group <-find_free_extent
  27464 up_read <-find_free_extent
  27486 __get_raid_index <-find_free_extent
  27503 _raw_spin_lock <-find_free_extent
  48335 search_bitmap <-btrfs_find_space_for_alloc

Is there anything to optimize? Can i speed up this?

There's still plenty of unallocated space:
# btrfs fi usage /vmbackup/
Overall:
    Device size:                  58.20TiB
    Device allocated:             22.66TiB
    Device unallocated:           35.54TiB
    Device missing:                  0.00B
    Used:                         21.07TiB
    Free (estimated):             37.12TiB      (min: 37.12TiB)
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:              512.00MiB      (used: 0.00B)

Data,RAID0: Size:22.57TiB, Used:20.99TiB
   /dev/sdc1       5.64TiB
   /dev/sdd1       5.64TiB
   /dev/sde1       5.64TiB
   /dev/sdf1       5.64TiB

Metadata,RAID0: Size:90.00GiB, Used:81.60GiB
   /dev/sdc1      22.50GiB
   /dev/sdd1      22.50GiB
   /dev/sde1      22.50GiB
   /dev/sdf1      22.50GiB

System,RAID0: Size:64.00MiB, Used:1.53MiB
   /dev/sdc1      16.00MiB
   /dev/sdd1      16.00MiB
   /dev/sde1      16.00MiB
   /dev/sdf1      16.00MiB

Unallocated:
   /dev/sdc1       8.88TiB
   /dev/sdd1       8.88TiB
   /dev/sde1       8.88TiB
   /dev/sdf1       8.88TiB

Is btrfs trying to hard to find free space?

Greets,
Stefan

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: btrfs is slow while looping in search_bitmap <-btrfs_find_space_for_alloc
  2017-09-05  5:58 btrfs is slow while looping in search_bitmap <-btrfs_find_space_for_alloc Stefan Priebe - Profihost AG
@ 2017-09-11  9:23 ` Stefan Priebe - Profihost AG
  0 siblings, 0 replies; 2+ messages in thread
From: Stefan Priebe - Profihost AG @ 2017-09-11  9:23 UTC (permalink / raw)
  To: linux-btrfs@vger.kernel.org

Am 05.09.2017 um 07:58 schrieb Stefan Priebe - Profihost AG:
> Hello,
> 
> while expecting slow btrfs volumes i switched to kernel v4.13 and to
> space_cache=v2.
...
> 
> Is btrfs trying to hard to find free space?
Even nobody replied - i reply to myself. I could completely "fix" this
by using ssd_spread option for my raid50.

Greets,
Stefan

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-09-11  9:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-05  5:58 btrfs is slow while looping in search_bitmap <-btrfs_find_space_for_alloc Stefan Priebe - Profihost AG
2017-09-11  9:23 ` Stefan Priebe - Profihost AG

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).