February 4, 2017 1:07 AM, "Goldwyn Rodrigues" <rgoldwyn@xxxxxxx> wrote: > On 02/03/2017 06:30 PM, Jorg Bornschein wrote: > >> February 3, 2017 11:26 PM, "Goldwyn Rodrigues" <rgoldwyn@xxxxxxxx> wrote: >> >> Hi, >> >> I'm currently running a balance (without any filters) on a 4 drives raid1 filesystem. The array >> contains 3 3TB drives and one 6TB drive; I'm running the rebalance because the 6TB drive recently >> replaced a 2TB drive. >> >> I know that balance is not supposed to be a fast operation, but this one is now running for ~6 days >> and it managed to balance ~18% (754 out of about 4250 chunks balanced (755 considered), 82% left) >> -- so I expect it to take another ~4 weeks. >> >> That seems excessively slow for ~8TiB of data. >> >> Is this expected behavior? In case it's not: Is there anything I can do to help debug it? >>> Do you have quotas enabled? >> >> I might have activated it when playing with "snapper" -- I remember using some quota command >> without knowing what it does. >> >> How can I check its active? Shall I just disable it wit "btrfs quota disable"? > > To check your quota limits: > # btrfs qgroup show <mountpoint> > > To disable > # btrfs quota disable <mountpoint> > > Yes, please check if disabling quotas makes a difference in execution > time of btrfs balance. Quata support was indeed active -- and it warned me that the qroup data was inconsistent. Disabling quotas had an immediate impact on balance throughput -- it's *much* faster now! >From a quick glance at iostat I would guess it's at least a factor 100 faster. Should quota support generally be disabled during balances? Or did I somehow push my fs into a weired state where it triggered a slow-path? Thanks! j -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
