Re: [PATCH v4 00/30] btrfs: add data write support for subpage

[riteshh <riteshh@linux.ibm.com>]

On 21/06/02 10:24AM, Qu Wenruo wrote:
>
>
> On 2021/6/2 上午10:22, riteshh wrote:
> > On 21/05/31 04:50PM, Qu Wenruo wrote:
> > > This huge patchset can be fetched from github:
> > > https://github.com/adam900710/linux/tree/subpage
> > >
> > > === Current stage ===
> > > The tests on x86 pass without new failure, and generic test group on
> > > arm64 with 64K page size passes except known failure and defrag group.
> > >
> > > For btrfs test group, all pass except compression/raid56/defrag.
> > >
> > > For anyone who is interested in testing, please apply this patch for
> > > btrfs-progs before testing.
> > > https://patchwork.kernel.org/project/linux-btrfs/patch/20210420073036.243715-1-wqu@suse.com/
> > > Or there will be too many false alerts.
> > >
> > > === Limitation ===
> > > There are several limitations introduced just for subpage:
> > > - No compressed write support
> > >    Read is no problem, but compression write path has more things left to
> > >    be modified.
> > >    Thus for current patchset, no matter what inode attribute or mount
> > >    option is, no new compressed extent can be created for subpage case.
> > >
> > > - No inline extent will be created
> > >    This is mostly due to the fact that filemap_fdatawrite_range() will
> > >    trigger more write than the range specified.
> > >    In fallocate calls, this behavior can make us to writeback which can
> > >    be inlined, before we enlarge the isize, causing inline extent being
> > >    created along with regular extents.
> > >
> > > - No support for RAID56
> > >    There are still too many hardcoded PAGE_SIZE in raid56 code.
> > >    Considering it's already considered unsafe due to its write-hole
> > >    problem, disabling RAID56 for subpage looks sane to me.
> > >
> > > - No defrag support for subpage
> > >    The support for subpage defrag has already an initial version
> > >    submitted to the mail list.
> > >    Thus the correct support won't be included in this patchset.
> > >
> > > === Patchset structure ===
> > >
> > > Patch 01~19:	Make data write path to be subpage compatible
> > > Patch 20~21:	Make data relocation path to be subpage compatible
> > > Patch 22~29:	Various fixes for subpage corner cases
> > > Patch 30:	Enable subpage data write
> > >
> > > === Changelog ===
> > > v2:
> > > - Rebased to latest misc-next
> > >    Now metadata write patches are removed from the series, as they are
> > >    already merged into misc-next.
> > >
> > > - Added new Reviewed-by/Tested-by/Reported-by tags
> > >
> > > - Use separate endio functions to subpage metadata write path
> > >
> > > - Re-order the patches, to make refactors at the top of the series
> > >    One refactor, the submit_extent_page() one, should benefit 4K page
> > >    size more than 64K page size, thus it's worthy to be merged early
> > >
> > > - New bug fixes exposed by Ritesh Harjani on Power
> > >
> > > - Reject RAID56 completely
> > >    Exposed by btrfs test group, which caused BUG_ON() for various sites.
> > >    Considering RAID56 is already not considered safe, it's better to
> > >    reject them completely for now.
> > >
> > > - Fix subpage scrub repair failure
> > >    Caused by hardcoded PAGE_SIZE
> > >
> > > - Fix free space cache inode size
> > >    Same cause as scrub repair failure
> > >
> > > v3:
> > > - Rebased to remove write path prepration patches
> > >
> > > - Properly enable btrfs defrag
> > >    Previsouly, btrfs defrag is in fact just disabled.
> > >    This makes tons of tests in btrfs/defrag to fail.
> > >
> > > - More bug fixes for rare race/crashes
> > >    * Fix relocation false alert on csum mismatch
> > >    * Fix relocation data corruption
> > >    * Fix a rare case of false ASSERT()
> > >      The fix already get merged into the prepration patches, thus no
> > >      longer in this patchset though.
> > >
> > >    Mostly reported by Ritesh from IBM.
> > >
> > > v4:
> > > - Disable subpage defrag completely
> > >    As full page defrag can race with fsstress in btrfs/062, causing
> > >    strange ordered extent bugs.
> > >    The full subpage defrag will be submitted as an indepdent patchset.
> >
> > Hello Qu,
> >
> > I have completed another 2 full iterations of testing this v4 with "-g all" on
> > Power. There are no failures reported (other than the known ones mostly due to
> > defrag disabled) and no kernel warnings/errors reported with v4 of your patch
> > series (other than a known one causing transaction abort -28 msg, but that seems
> > to be triggering even w/o your patch series i.e. with 64k blocksize too).
> >
> >  From the test perspective, please feel free to add below for your v4.
> >
> > Tested-by: Ritesh Harjani <riteshh@linux.ibm.com> 		[ppc64]
> >
> >
> > I think since this patch series looks good, I can now start helping with defrag
> > patch series of yours :)
> > That should be on top of this v4 I guess.
>
> Exactly, and that has been just submitted.
>
> You can also fetch the branch from 'defrag_refactor' branch from my github
> repo.
>
> And since that branch only touches defrag ioctl, free feel to just test '-g
> defrag' test cases if you want a quick run.

Great! Thanks for the quick response.
Will start my testing.

-ritesh