Re: [PATCH v2 00/17] btrfs: add subpage support for RAID56

[David Sterba <dsterba@suse.cz>]

On Tue, Apr 12, 2022 at 07:42:25PM +0200, David Sterba wrote:
> On Tue, Apr 12, 2022 at 05:32:50PM +0800, Qu Wenruo wrote:
> > The branch can be fetched from github, based on latest misc-next branch
> > (with bio and memory allocation refactors):
> > https://github.com/adam900710/linux/tree/subpage_raid56
> > 
> > [CHANGELOG]
> > v2:
> > - Rebased to latest misc-next
> >   There are several conflicts caused by bio interface change and page
> >   allocation update.
> > 
> > - A new patch to reduce the width of @stripe_len to u32
> >   Currently @stripe_len is fixed to 64K, and even in the future we
> >   choose to enlarge the value, I see no reason to go beyond 4G for
> >   stripe length.
> > 
> >   Thus change it u32 to avoid some u64-divided-by-u32 situations.
> > 
> >   This will reduce memory usage for map_lookup (which has a lifespan as
> >   long as the mounted fs) and btrfs_io_geometry (which only has a very
> >   short lifespan, mostly bounded to bio).
> > 
> >   Furthermore, add some extra alignment check and use right bit shift
> >   to replace involved division to avoid possible problems on 32bit
> >   systems.
> > 
> > - Pack sector_ptr::pgoff and sector_ptr::uptodate into one u32
> >   This will reduce memory usage and reduce unaligned memory access
> > 
> >   Please note that, even with it packed, we still have a 4 bytes padding
> >   (it's u64 + u32, thus not perfectly aligned).
> >   Without packed attribute, it will cost more memory usage anyway.
> > 
> > - Call kunmap_local() using address with pgoff
> >   As it can handle it without problem, no need to bother extra search
> >   just for pgoff.
> > 
> > - Use "= { 0 }" for structure initialization
> > 
> > - Reduce comment updates to minimal
> >   If one comment line is not really touched, then don't touch it just to
> >   fix some bad styles.
> 
> v2 updated in for-next, I had a local branch with more changes so I
> transferred the changes manually.

Now moved to misc-next as it's an isolated functionality and should not
affect anything else. Thanks.