Re: About the md-bitmap behavior

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/6/24 08:55, Jani Partanen wrote:
>
>
> Qu Wenruo kirjoitti 23/06/2022 klo 7.52:
>> That makes sense, but that also means the extent allocator needs extra
>> info, not just which space is available.
>>
>> And there would make ENOSPC handling even more challenging, what if we
>> have no space left but only partially written stripes?
>>
>> There are some ideas, like extra layer for RAID56 to do extra mapping
>> between logical address to physical address, but I'm not yet confident
>> if we will see new (and even more complex) challenges going that path.
>
> Isn't there already in btrfs system in place for ENOSPC situation?

It's not perfect, we still have some of reports of ENOSPC in the most
inconvenient timing from time to time.

> You
> just add some space temporaly?

That is not a valid solution, not even a valid workaround.

> Thats what I remember when I was playing
> around with different situations with btrfs.

The situation is improving a lot recently, but it's still far from
write-in-place fs level.

> For me bigger issue with btrfs raid56 is the fact that scrub is very
> very slow. That should be one of the top priority to solve.

In fact, that's caused by the way how we do scrub.
We start a scrub for each device, this is mostly fine for regular
profiles, but a big no no to RAID56.

Since scrub a full stripe will read all data/P/Q from disk, it makes no
sense to scrub a full stripe multiple times.

That would be a target during the write-intent bitmap, as we will rely
on scrub to re-sync the data at recovery time.


After that, I'll try to create a better, RAID56 friendly interface for
scrub ioctl.

Thanks,
Qu

>
> // JiiPee