Re: "kernel BUG" and segmentation fault with "device delete"

[Vladimir Panteleev <thecybershadow@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1593 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]