On 12/25/19 8:39 AM, Qu Wenruo wrote:
For the following disk layout, can_overcommit() can cause false confidence in available space: devid 1 unallocated: 1T devid 2 unallocated: 10T metadata type: RAID1 As can_overcommit() simply uses unallocated space with factor to calculate the allocatable metadata chunk size. can_overcommit() believes we still have 5.5T for metadata chunks, while the truth is, we only have 1T available for metadata chunks. This can lead to ENOSPC at run_delalloc_range() and cause transaction abort. Since factor based calculation can't distinguish RAID1/RAID10 and DUP at all, we need proper chunk-allocator level awareness to do such estimation. Thankfully, we have per-profile available space already calculated, just use that facility to avoid such false confidence. Reported-by: Marc Lehmann <schmorp@xxxxxxxxxx> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Thanks, Josef
