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
