On 2019/11/22 下午10:43, Christian Pernegger wrote: > Am Fr., 22. Nov. 2019 um 13:34 Uhr schrieb Qu Wenruo <quwenruo.btrfs@xxxxxxx>: >> But still, for snapshot deletion part, there is still a performance impact. > > Ok. It's just that I'd have expected *slower* write and read > performance until everything's settled, maybe sync writes taking > noticeably longer than usual, not that all user input blocks across > the whole system regardless of fs activity. The slowdown happens in commit transaction, and with commit transaction, a lot of operation is blocked until current transaction is committed. That's why it blocks everything. We had tried our best to reduce the impact, but deletion is still a big problem, as it can cause tons of extents to change their owner, thus cause the problem. In short, unless you really need to know how many bytes each snapshots really takes, then disable qgroup. And BTW, for "many" subvolumes/snapshots, I guess we mean 20. 200 is already prone to cause problem, not only qgroups, but also send. So it's also recommended to reduce the number of snapshots. Thanks, Qu > > Cheers, > C. >
Attachment:
signature.asc
Description: OpenPGP digital signature
