All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz, Neal Gompa <ngompa13@gmail.com>,
	Qu Wenruo <wqu@suse.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v6 00/15] btrfs: add data write support for subpage
Date: Thu, 8 Jul 2021 13:27:00 +0200	[thread overview]
Message-ID: <20210708112700.GW2610@twin.jikos.cz> (raw)
In-Reply-To: <843d839c-11f5-40e3-9871-e462254113b1@gmx.com>

On Thu, Jul 08, 2021 at 07:19:28AM +0800, Qu Wenruo wrote:
> 
> 
> On 2021/7/8 上午2:14, David Sterba wrote:
> > On Wed, Jul 07, 2021 at 01:41:46PM -0400, Neal Gompa wrote:
> >>> But on the other hand, I'm not sure what's the proper way to introduce a
> >>> fix for v5.15 window.
> >>>
> >>> Should I just disable readahead for compression read (which just needs
> >>> two lines to return 0 for subpage case in add_ra_bio_pages())?
> >>>
> >>> Or should I add the proper fix into the patchset?
> >>
> >> If this is going into 5.15 instead of 5.14, just add the proper fix
> >> into this patch set. But if we want to land this in 5.14, I would
> >> suggest disabling it for now and then having a separate patch set for
> >> that.
> >
> > 5.14 is not possible, there are other subpage changes already merged so
> > fixes to existing level of support (still limited) can go to 5.14-rcs
> > but this whole patchses it is targeting 5.15.
> >
> >> You're already targeting 5.15 (though I kind of want this in 5.14...),
> >> so I suggest going with adding the fix to the patch set.
> >
> > For 5.15 it's free to do any change, eg. fold the fix or do a separate
> > patch explaining all the details.
> 
> Another reason why I'm considering to disable that readahead ability is,
> it really makes little sense for 64K page size.
> 
> Our maximum compressed extent size is just 128K, at most 3 pages for 64K
> page size (that's when the extent is not page aligned).
> 
> Just saving two reads (which may only be one or 2 4K sectors) doesn't
> really make it worthy, especially considering the change to ra itself is
> going to affecting common code path.
> 
> Thus I prefer to disable for the initial support, and only add the
> proper fix for the compression write support.

Ok.

> > In general the development changes must be ready at the rc5 time at the
> > latest (with a week or two for some testing and catching last bugs).
> > Once it's due there's like two months until the next code freeze.
> >
> 
> Great, I'll just add a simple disabling patch with comments on why the
> current code doesn't work and why it's fine to disable it for 64K page size.

Yes please, there's a number of things that won't be initially
implemented so we need to keep track (changelogs and/or comments).

      reply	other threads:[~2021-07-08 11:29 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05  2:00 [PATCH v6 00/15] btrfs: add data write support for subpage Qu Wenruo
2021-07-05  2:00 ` [PATCH v6 01/15] btrfs: grab correct extent map for subpage compressed extent read Qu Wenruo
2021-07-08  6:50   ` Anand Jain
2021-07-08  7:06     ` Qu Wenruo
2021-07-09  9:13       ` Anand Jain
2021-07-05  2:00 ` [PATCH v6 02/15] btrfs: remove the GFP_HIGHMEM flag for compression code Qu Wenruo
2021-07-08 11:54   ` David Sterba
2021-07-08 12:11     ` Qu Wenruo
2021-07-05  2:00 ` [PATCH v6 03/15] btrfs: rework btrfs_decompress_buf2page() Qu Wenruo
2021-07-09 18:53   ` David Sterba
2021-07-09 22:03     ` Qu Wenruo
2021-07-09 19:26   ` David Sterba
2021-07-05  2:00 ` [PATCH v6 04/15] btrfs: rework lzo_decompress_bio() to make it subpage compatible Qu Wenruo
2021-07-09 20:37   ` David Sterba
2021-07-05  2:01 ` [PATCH v6 05/15] btrfs: extract relocation page read and dirty part into its own function Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 06/15] btrfs: make relocate_one_page() to handle subpage case Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 07/15] btrfs: fix wild subpage writeback which does not have ordered extent Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 08/15] btrfs: disable inline extent creation for subpage Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 09/15] btrfs: allow submit_extent_page() to do bio split " Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 10/15] btrfs: reject raid5/6 fs " Qu Wenruo
2021-07-09  9:36   ` Anand Jain
2021-07-09 18:34     ` David Sterba
2021-07-05  2:01 ` [PATCH v6 11/15] btrfs: fix a crash caused by race between prepare_pages() and btrfs_releasepage() Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 12/15] btrfs: fix a use-after-free bug in writeback subpage helper Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 13/15] btrfs: fix a subpage false alert for relocating partial preallocated data extents Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 14/15] btrfs: fix a subpage relocation data corruption Qu Wenruo
2021-07-05  2:01 ` [PATCH v6 15/15] btrfs: allow read-write for 4K sectorsize on 64K page size systems Qu Wenruo
2021-07-07  8:28 ` [PATCH v6 00/15] btrfs: add data write support for subpage Qu Wenruo
2021-07-07 17:41   ` Neal Gompa
2021-07-07 18:14     ` David Sterba
2021-07-07 23:19       ` Qu Wenruo
2021-07-08 11:27         ` David Sterba [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210708112700.GW2610@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=ngompa13@gmail.com \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.