Re: [PATCH 1/2] btrfs: introduce btrfs_subpage_bitmap_info

[David Sterba <dsterba@suse.cz>]

On Mon, Aug 16, 2021 at 06:12:16PM +0800, Qu Wenruo wrote:
> > Also I believe a graphical representation is in order i.e
> >
> > [u][u][u][u][e][e][e][e][e]
> > ^			  ^
> > |-uptodate_start	  |- error_start etc
> 
> That looks awesome.
> 
> > Since it's a bit unexpected to have multiple, logically independent
> > bitmaps be tracked in the same physical location.
> 
> That's also I'm concerning of.
> 
> I haven't seen other code sides doing the same behavior.
> IOmap just waste all the memory by going full u32 bitmap even for case
> like 16K page size and 4K sectorsize, exactly I want to avoid.

Yeah, it is mixing independent things in one structure, but that is to
decrease the waste and memory consumption. The subpage is attached to
each page, that come in large numbers so this is a justified
optimization, even if it's not "conceptually clean".

In the first implementation there were 4 bitmaps, so we see how things
work without the optimization. The switch to one bitmap was about to
happen once we get things working.