* qgroup code slowing down rebalance @ 2016-03-16 20:53 Dave Hansen 2016-03-17 1:36 ` Qu Wenruo 0 siblings, 1 reply; 6+ messages in thread From: Dave Hansen @ 2016-03-16 20:53 UTC (permalink / raw) To: linux-btrfs, Qu Wenruo, Chris Mason I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :) During this rebalance, the disks were pretty lightly used. I would see a small burst of tens of MB/s, then it would go back to no activity for a few minutes, small burst, no activity, etc... During the quiet times (for the disk) one processor would be pegged inside the kernel and would have virtually no I/O wait time. Also during this time, the filesystem was pretty unbearably slow. An ls of a small directory would hang for minutes. A perf profile shows 92% of the cpu time is being spend in btrfs_find_all_roots(), called under this call path: btrfs_commit_transaction -> btrfs_qgroup_prepare_account_extents -> btrfs_find_all_roots So I tried disabling quotas by doing: btrfs quota disable /mnt/foo which took a few minutes to complete, but once it did, the disks went back up to doing ~200MB/s, the kernel time went down to ~20%, and the system now has lots of I/O wait time. It looks to be behaving nicely. Is this expected? From my perspective, it makes quotas pretty much unusable at least during a rebalance. I have a full 'perf record' profile with call graphs if it would be helpful. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qgroup code slowing down rebalance 2016-03-16 20:53 qgroup code slowing down rebalance Dave Hansen @ 2016-03-17 1:36 ` Qu Wenruo 2016-03-17 16:36 ` Dave Hansen 0 siblings, 1 reply; 6+ messages in thread From: Qu Wenruo @ 2016-03-17 1:36 UTC (permalink / raw) To: Dave Hansen, linux-btrfs, Chris Mason Dave Hansen wrote on 2016/03/16 13:53 -0700: > I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB > total) running under 4.5.0-rc5. I recently added a disk and needed to > rebalance. I started a rebalance operation three days ago. It was on > the order of 20% done after those three days. :) > > During this rebalance, the disks were pretty lightly used. I would see > a small burst of tens of MB/s, then it would go back to no activity for > a few minutes, small burst, no activity, etc... During the quiet times > (for the disk) one processor would be pegged inside the kernel and would > have virtually no I/O wait time. Also during this time, the filesystem > was pretty unbearably slow. An ls of a small directory would hang for > minutes. > > A perf profile shows 92% of the cpu time is being spend in > btrfs_find_all_roots(), called under this call path: > > btrfs_commit_transaction > -> btrfs_qgroup_prepare_account_extents > -> btrfs_find_all_roots > > So I tried disabling quotas by doing: > > btrfs quota disable /mnt/foo > > which took a few minutes to complete, but once it did, the disks went > back up to doing ~200MB/s, the kernel time went down to ~20%, and the > system now has lots of I/O wait time. It looks to be behaving nicely. > > Is this expected? From my perspective, it makes quotas pretty much > unusable at least during a rebalance. I have a full 'perf record' > profile with call graphs if it would be helpful. > > Thanks for the report. Again balance, the devil is again(always) in the balance. To be honest, balance itself is already complicated enough, and not a friendly neighborhood for a lot of function. (Yeah, a lot of dedupe bugs are and can only be triggered by balance, and I can't hate it any more) Perf record profile will help a lot. Please upload it if it's OK for you. Also, the following data would help a lot: 1) btrfs fi df output To determine the metadata/data ratio Balancing metadata should be quite slow. 2) btrfs subvolume list output To determine how many tree blocks are shared against each other More shared tree blocks, slower quota routing is. Feel free to mask the output to avoid information leaking. 3) perf record for balancing metadata and data respectively Although this is optional. Just to prove some assumption. btrfs_find_all_roots() is quite a slow operation, and in its worst case (tree blocks are shared by a lot of trees) it may be near O(2^n). For normal operation, it's pretty hard to trigger so many extents creation/deletion/reference. Even such case happens, it will cause much much much more IO, making the most time waiting IO other than doing quota accounting. But for balance, especially for metadata balancing, IO is small but amount of extents is very high, making most the time consumed by find_all_roots(). I can try to make balance to bypass quota routine, but I'm not sure if such operation will open another hole to make quota crazy again, and only much much much more tests can prove it. :( Thanks, Qu ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qgroup code slowing down rebalance 2016-03-17 1:36 ` Qu Wenruo @ 2016-03-17 16:36 ` Dave Hansen 2016-03-18 1:02 ` Qu Wenruo 0 siblings, 1 reply; 6+ messages in thread From: Dave Hansen @ 2016-03-17 16:36 UTC (permalink / raw) To: Qu Wenruo, linux-btrfs, Chris Mason On 03/16/2016 06:36 PM, Qu Wenruo wrote: > Dave Hansen wrote on 2016/03/16 13:53 -0700: >> I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB >> total) running under 4.5.0-rc5. I recently added a disk and needed to >> rebalance. I started a rebalance operation three days ago. It was on >> the order of 20% done after those three days. :) ... > Perf record profile will help a lot. > Please upload it if it's OK for you. I'll send it privately. But, I do see basically the same behavior when balancing data and metadata. I profiled both. > Also, the following data would help a lot: > 1) btrfs fi df output > To determine the metadata/data ratio > Balancing metadata should be quite slow. Data, RAID1: total=4.53TiB, used=4.53TiB System, RAID1: total=32.00MiB, used=720.00KiB Metadata, RAID1: total=17.00GiB, used=15.77GiB GlobalReserve, single: total=512.00MiB, used=0.00B > 2) btrfs subvolume list output > To determine how many tree blocks are shared against each other > More shared tree blocks, slower quota routing is. > > Feel free to mask the output to avoid information leaking. Here you go (pasted at the end). You can pretty clearly see that I'm using this volume for incremental backups. My plan was to keep the old snapshots around until the filesystem fills up. > 3) perf record for balancing metadata and data respectively > Although this is optional. Just to prove some assumption. > > btrfs_find_all_roots() is quite a slow operation, and in its worst case > (tree blocks are shared by a lot of trees) it may be near O(2^n). Yikes! But, that does look to be consistent with what I'm seeing. >> ID 15183 gen 207620 top level 5 path blackbird_backups.enc >> ID 15547 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779116 >> ID 15548 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779185 >> ID 15559 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814382 >> ID 15560 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814540 >> ID 15561 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814739 >> ID 15562 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814783 >> ID 15563 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815180 >> ID 15564 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815259 >> ID 15565 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815314 >> ID 15566 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815948 >> ID 15567 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816104 >> ID 15568 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816127 >> ID 15569 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816213 >> ID 15570 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816305 >> ID 15571 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816591 >> ID 15572 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816622 >> ID 15573 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816632 >> ID 15574 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816638 >> ID 15575 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816837 >> ID 15576 gen 207620 top level 5 path home-backup-on-btrfs.enc >> ID 16634 gen 207620 top level 5 path homes-backup-nimitz-o2.enc >> ID 17389 gen 207620 top level 5 path snapshots/root/1456271568 >> ID 17390 gen 207620 top level 5 path snapshots/root/1456272221 >> ID 17391 gen 207620 top level 5 path snapshots/root/1456416369 >> ID 17392 gen 207620 top level 5 path snapshots/root/1456435609 >> ID 17393 gen 207620 top level 5 path snapshots/root/1456539873 >> ID 17394 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456553298 >> ID 17395 gen 207620 top level 5 path snapshots/root/1456553448 >> ID 17396 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553460 >> ID 17397 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553461 >> ID 17398 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602362 >> ID 17399 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602405 >> ID 17400 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456602405 >> ID 17401 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456628682 >> ID 17402 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456628682 >> ID 17403 gen 207620 top level 5 path snapshots/root/1456628682 >> ID 17404 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456675846 >> ID 17405 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456675846 >> ID 17406 gen 207620 top level 5 path snapshots/root/1456675846 >> ID 17407 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456713915 >> ID 17408 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456720748 >> ID 17409 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722793 >> ID 17410 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722812 >> ID 17411 gen 207620 top level 5 path snapshots/root/1456722812 >> ID 17412 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456722812 >> ID 17413 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456731271 >> ID 17414 gen 207620 top level 5 path snapshots/root/1456731271 >> ID 17415 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456731271 >> ID 17416 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456838946 >> ID 17417 gen 207620 top level 5 path snapshots/root/1456838946 >> ID 17418 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456838946 >> ID 17419 gen 207620 top level 5 path snapshots/root/1457127404 >> ID 17420 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457127404 >> ID 17421 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1457127404 >> ID 17422 gen 207620 top level 5 path snapshots/root/1457138948 >> ID 17423 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457138948 >> ID 17425 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457451483 >> ID 17426 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457808380 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qgroup code slowing down rebalance 2016-03-17 16:36 ` Dave Hansen @ 2016-03-18 1:02 ` Qu Wenruo 2016-03-18 16:33 ` Dave Hansen 0 siblings, 1 reply; 6+ messages in thread From: Qu Wenruo @ 2016-03-18 1:02 UTC (permalink / raw) To: Dave Hansen, linux-btrfs, Chris Mason Dave Hansen wrote on 2016/03/17 09:36 -0700: > On 03/16/2016 06:36 PM, Qu Wenruo wrote: >> Dave Hansen wrote on 2016/03/16 13:53 -0700: >>> I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB >>> total) running under 4.5.0-rc5. I recently added a disk and needed to >>> rebalance. I started a rebalance operation three days ago. It was on >>> the order of 20% done after those three days. :) > ... >> Perf record profile will help a lot. >> Please upload it if it's OK for you. > > I'll send it privately. > > But, I do see basically the same behavior when balancing data and > metadata. I profiled both. > >> Also, the following data would help a lot: >> 1) btrfs fi df output >> To determine the metadata/data ratio >> Balancing metadata should be quite slow. > > Data, RAID1: total=4.53TiB, used=4.53TiB > System, RAID1: total=32.00MiB, used=720.00KiB > Metadata, RAID1: total=17.00GiB, used=15.77GiB > GlobalReserve, single: total=512.00MiB, used=0.00B Considering the size and the amount of metadata, even doing a quota rescan will be quite slowing. Would you please try to do a quota rescan and see the CPU/IO usage? > > >> 2) btrfs subvolume list output >> To determine how many tree blocks are shared against each other >> More shared tree blocks, slower quota routing is. >> >> Feel free to mask the output to avoid information leaking. > > Here you go (pasted at the end). You can pretty clearly see that I'm > using this volume for incremental backups. My plan was to keep the old > snapshots around until the filesystem fills up. Oh, find_all_roots() nightmare, just as mentioned, it will slow quota rescan too. > >> 3) perf record for balancing metadata and data respectively >> Although this is optional. Just to prove some assumption. >> >> btrfs_find_all_roots() is quite a slow operation, and in its worst case >> (tree blocks are shared by a lot of trees) it may be near O(2^n). > > Yikes! But, that does look to be consistent with what I'm seeing. So, you mean time consumed by find_all_roots() is consistent? Then it must be quite slow for almost all tree blocks... Anyway, I'd better try to allow balance to by-pass quota accounting. Thanks, Qu > >>> ID 15183 gen 207620 top level 5 path blackbird_backups.enc >>> ID 15547 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779116 >>> ID 15548 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779185 >>> ID 15559 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814382 >>> ID 15560 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814540 >>> ID 15561 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814739 >>> ID 15562 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814783 >>> ID 15563 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815180 >>> ID 15564 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815259 >>> ID 15565 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815314 >>> ID 15566 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815948 >>> ID 15567 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816104 >>> ID 15568 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816127 >>> ID 15569 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816213 >>> ID 15570 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816305 >>> ID 15571 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816591 >>> ID 15572 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816622 >>> ID 15573 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816632 >>> ID 15574 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816638 >>> ID 15575 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816837 >>> ID 15576 gen 207620 top level 5 path home-backup-on-btrfs.enc >>> ID 16634 gen 207620 top level 5 path homes-backup-nimitz-o2.enc >>> ID 17389 gen 207620 top level 5 path snapshots/root/1456271568 >>> ID 17390 gen 207620 top level 5 path snapshots/root/1456272221 >>> ID 17391 gen 207620 top level 5 path snapshots/root/1456416369 >>> ID 17392 gen 207620 top level 5 path snapshots/root/1456435609 >>> ID 17393 gen 207620 top level 5 path snapshots/root/1456539873 >>> ID 17394 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456553298 >>> ID 17395 gen 207620 top level 5 path snapshots/root/1456553448 >>> ID 17396 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553460 >>> ID 17397 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553461 >>> ID 17398 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602362 >>> ID 17399 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602405 >>> ID 17400 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456602405 >>> ID 17401 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456628682 >>> ID 17402 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456628682 >>> ID 17403 gen 207620 top level 5 path snapshots/root/1456628682 >>> ID 17404 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456675846 >>> ID 17405 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456675846 >>> ID 17406 gen 207620 top level 5 path snapshots/root/1456675846 >>> ID 17407 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456713915 >>> ID 17408 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456720748 >>> ID 17409 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722793 >>> ID 17410 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722812 >>> ID 17411 gen 207620 top level 5 path snapshots/root/1456722812 >>> ID 17412 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456722812 >>> ID 17413 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456731271 >>> ID 17414 gen 207620 top level 5 path snapshots/root/1456731271 >>> ID 17415 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456731271 >>> ID 17416 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456838946 >>> ID 17417 gen 207620 top level 5 path snapshots/root/1456838946 >>> ID 17418 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456838946 >>> ID 17419 gen 207620 top level 5 path snapshots/root/1457127404 >>> ID 17420 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457127404 >>> ID 17421 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1457127404 >>> ID 17422 gen 207620 top level 5 path snapshots/root/1457138948 >>> ID 17423 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457138948 >>> ID 17425 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457451483 >>> ID 17426 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457808380 > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qgroup code slowing down rebalance 2016-03-18 1:02 ` Qu Wenruo @ 2016-03-18 16:33 ` Dave Hansen 2016-03-21 1:44 ` Qu Wenruo 0 siblings, 1 reply; 6+ messages in thread From: Dave Hansen @ 2016-03-18 16:33 UTC (permalink / raw) To: Qu Wenruo, linux-btrfs, Chris Mason On 03/17/2016 06:02 PM, Qu Wenruo wrote: > Dave Hansen wrote on 2016/03/17 09:36 -0700: >> On 03/16/2016 06:36 PM, Qu Wenruo wrote: >>> Dave Hansen wrote on 2016/03/16 13:53 -0700: >>>> I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB >>>> total) running under 4.5.0-rc5. I recently added a disk and needed to >>>> rebalance. I started a rebalance operation three days ago. It was on >>>> the order of 20% done after those three days. :) >> ... >> Data, RAID1: total=4.53TiB, used=4.53TiB >> System, RAID1: total=32.00MiB, used=720.00KiB >> Metadata, RAID1: total=17.00GiB, used=15.77GiB >> GlobalReserve, single: total=512.00MiB, used=0.00B > > Considering the size and the amount of metadata, even doing a quota > rescan will be quite slowing. > > Would you please try to do a quota rescan and see the CPU/IO usage? I did a quota rescan. It uses about 80% of one CPU core, but also has some I/O wait time and pulls 1-20MB/s of data off the disk (the balance with quotas on was completely CPU-bound, and had very low I/O rates). It would seem that the "quota rescan" *does* have the same issue as the balance with quotas on, but to a much smaller extent than what I saw with the "balance" operation. I have a full profile recorded from the "quota rescan", but the most relevant parts are pasted below. Basically btrfs_search_slot() and radix tree lookups are eating all the CPU time, but they're still doing enough I/O to see _some_ idle time on the processor. > 74.55% 3.10% kworker/u8:0 [btrfs] [k] find_parent_nodes > | > ---find_parent_nodes > | > |--99.95%-- __btrfs_find_all_roots > | btrfs_find_all_roots > | btrfs_qgroup_rescan_worker > | normal_work_helper > | btrfs_qgroup_rescan_helper > | process_one_work > | worker_thread > | kthread > | ret_from_fork > --0.05%-- [...] > > 32.14% 4.16% kworker/u8:0 [btrfs] [k] btrfs_search_slot > | > ---btrfs_search_slot > | > |--87.90%-- find_parent_nodes > | __btrfs_find_all_roots > | btrfs_find_all_roots > | btrfs_qgroup_rescan_worker > | normal_work_helper > | btrfs_qgroup_rescan_helper > | process_one_work > | worker_thread > | kthread > | ret_from_fork > | > |--11.70%-- btrfs_search_old_slot > | __resolve_indirect_refs > | find_parent_nodes > | __btrfs_find_all_roots > | btrfs_find_all_roots > | btrfs_qgroup_rescan_worker > | normal_work_helper > | btrfs_qgroup_rescan_helper > | process_one_work > | worker_thread > | kthread > | ret_from_fork > --0.39%-- [...] > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: qgroup code slowing down rebalance 2016-03-18 16:33 ` Dave Hansen @ 2016-03-21 1:44 ` Qu Wenruo 0 siblings, 0 replies; 6+ messages in thread From: Qu Wenruo @ 2016-03-21 1:44 UTC (permalink / raw) To: Dave Hansen, linux-btrfs, Chris Mason Dave Hansen wrote on 2016/03/18 09:33 -0700: > On 03/17/2016 06:02 PM, Qu Wenruo wrote: >> Dave Hansen wrote on 2016/03/17 09:36 -0700: >>> On 03/16/2016 06:36 PM, Qu Wenruo wrote: >>>> Dave Hansen wrote on 2016/03/16 13:53 -0700: >>>>> I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB >>>>> total) running under 4.5.0-rc5. I recently added a disk and needed to >>>>> rebalance. I started a rebalance operation three days ago. It was on >>>>> the order of 20% done after those three days. :) >>> ... >>> Data, RAID1: total=4.53TiB, used=4.53TiB >>> System, RAID1: total=32.00MiB, used=720.00KiB >>> Metadata, RAID1: total=17.00GiB, used=15.77GiB >>> GlobalReserve, single: total=512.00MiB, used=0.00B >> >> Considering the size and the amount of metadata, even doing a quota >> rescan will be quite slowing. >> >> Would you please try to do a quota rescan and see the CPU/IO usage? > > I did a quota rescan. It uses about 80% of one CPU core, but also has > some I/O wait time and pulls 1-20MB/s of data off the disk (the balance > with quotas on was completely CPU-bound, and had very low I/O rates). > > It would seem that the "quota rescan" *does* have the same issue as the > balance with quotas on, but to a much smaller extent than what I saw > with the "balance" operation. This is quite expected. Most CPU would be consumed by find_all_roots(), as your subvolume layout is the just the worst case for find_all_roots(). That's to say, remove unneeded snapshots and keep them under a limited amount would be the best case. Btrfs snapshot is superfast to create, but the design implies a lot of overhead for some minor operation, especially for backref lookup. And unfortunately, quota relies heavily on it. The only difference that I doesn't expect is IO. As I expected rescan would be much the same with balance, with little IO. Did you run rescan/balance after dropping all the caches? Although for balance, I would add some patch to make them by-pass quota accounting as them seems to be OK. But for rescan case, AFAIK that's the case. BTW although it's quite risky, I hope you can run some old kernels and see the performance difference of rescan and balance. For old kernels, I mean 4.1 which is the latest kernel that doesn't use the new quota framework. I'm very interesting to see if the old but wrong code would have a better or worse performance on balance or rescan. Thank you very much for all this quota related reports. Qu > > I have a full profile recorded from the "quota rescan", but the most > relevant parts are pasted below. Basically btrfs_search_slot() and > radix tree lookups are eating all the CPU time, but they're still doing > enough I/O to see _some_ idle time on the processor. > >> 74.55% 3.10% kworker/u8:0 [btrfs] [k] find_parent_nodes >> | >> ---find_parent_nodes >> | >> |--99.95%-- __btrfs_find_all_roots >> | btrfs_find_all_roots >> | btrfs_qgroup_rescan_worker >> | normal_work_helper >> | btrfs_qgroup_rescan_helper >> | process_one_work >> | worker_thread >> | kthread >> | ret_from_fork >> --0.05%-- [...] >> >> 32.14% 4.16% kworker/u8:0 [btrfs] [k] btrfs_search_slot >> | >> ---btrfs_search_slot >> | >> |--87.90%-- find_parent_nodes >> | __btrfs_find_all_roots >> | btrfs_find_all_roots >> | btrfs_qgroup_rescan_worker >> | normal_work_helper >> | btrfs_qgroup_rescan_helper >> | process_one_work >> | worker_thread >> | kthread >> | ret_from_fork >> | >> |--11.70%-- btrfs_search_old_slot >> | __resolve_indirect_refs >> | find_parent_nodes >> | __btrfs_find_all_roots >> | btrfs_find_all_roots >> | btrfs_qgroup_rescan_worker >> | normal_work_helper >> | btrfs_qgroup_rescan_helper >> | process_one_work >> | worker_thread >> | kthread >> | ret_from_fork >> --0.39%-- [...] >> > > > > -- > 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-03-21 1:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-16 20:53 qgroup code slowing down rebalance Dave Hansen 2016-03-17 1:36 ` Qu Wenruo 2016-03-17 16:36 ` Dave Hansen 2016-03-18 1:02 ` Qu Wenruo 2016-03-18 16:33 ` Dave Hansen 2016-03-21 1:44 ` Qu Wenruo
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).