On 06/07/2019 05.01, Qu Wenruo wrote:
After stubbing out btrfs_check_rw_degradable (because btrfs currently can't realize when it has all drives needed for RAID10),The point is, btrfs_check_rw_degradable() is already doing per-chunk level rw degradable checking. I would highly recommend not to comment out the function completely. It has been a long (well, not that long) way from old fs level tolerance to current per-chunk tolerance check.
Very grateful for this :)
I totally understand for RAID10 we can at most drop half of its stripes as long as we have one device for each substripe. If you really want that feature to allow RAID10 to tolerate more missing devices, please do proper chunk stripe check.
This was my understanding of the situation as well; in any case, it was a temporary patch just so I could rebalance the RAID10 blocks to RAID1.
The fs should have enough space to allocate new metadata chunk (it's metadata chunk lacking space and caused ENOSPC). I'm not sure if it's the degraded mount cause the problem, as the enospc_debug output looks like reserved/pinned/over-reserved space has taken up all space, while no new chunk get allocated.
The problem happens after replace-ing the missing device (which succeeds in full) and then attempting to remove it, i.e. without a degraded mount.
Would you please try to balance metadata to see if the ENOSPC still happens?
The problem also manifests when attempting to rebalance the metadata. Thanks! -- Best regards, Vladimir
signature.asc
Description: OpenPGP digital signature
