All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC 0/8] btrfs: experimental compression support for subpage
Date: Thu, 24 Jun 2021 06:54:32 +0800	[thread overview]
Message-ID: <860ea877-1986-c6c6-625f-ea3e2224c676@suse.com> (raw)
In-Reply-To: <20210623223740.GQ28158@twin.jikos.cz>



On 2021/6/24 上午6:37, David Sterba wrote:
> On Wed, Jun 23, 2021 at 01:55:21PM +0800, Qu Wenruo wrote:
>> Qu Wenruo (8):
>>    btrfs: don't pass compressed pages to
>>      btrfs_writepage_endio_finish_ordered()
>>    btrfs: make btrfs_subpage_end_and_test_writer() to handle pages not
>>      locked by btrfs_page_start_writer_lock()
>>    btrfs: make compress_file_range() to be subpage compatible
>>    btrfs: make btrfs_submit_compressed_write() to be subpage compatible
>>    btrfs: use async_chunk::async_cow to replace the confusing pending
>>      pointer
>>    btrfs: make end_compressed_bio_writeback() to be subpage compatble
>>    btrfs: make extent_write_locked_range() to be subpage compatible
>>    btrfs: only allow subpage compression if the range fully covers the
>>      first page
> 
> Some of the patches seem independent and potentially could be taken into
> 5.14 now but I guess the whole subpage could go in one big batch to 5.15
> so it won't help you much anyway. The significant change is the last
> patch and so far I think it's acceptable.
> 
Nonononono, please don't merge any patche from the series.

As the patches are not fully stress tested, and I have already seen some 
ASSERT()s triggered, thus there must be something wrong in the 
preparation part.

Sorry I should have added some warning like "WIP, don't merge any patch 
in the series".

This is mostly for the discussion on the last patch, not really to get 
any patch merged.

Thanks,
Qu


      reply	other threads:[~2021-06-23 22:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23  5:55 [PATCH RFC 0/8] btrfs: experimental compression support for subpage Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 1/8] btrfs: don't pass compressed pages to btrfs_writepage_endio_finish_ordered() Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 2/8] btrfs: make btrfs_subpage_end_and_test_writer() to handle pages not locked by btrfs_page_start_writer_lock() Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 3/8] btrfs: make compress_file_range() to be subpage compatible Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 4/8] btrfs: make btrfs_submit_compressed_write() " Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 5/8] btrfs: use async_chunk::async_cow to replace the confusing pending pointer Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 6/8] btrfs: make end_compressed_bio_writeback() to be subpage compatble Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 7/8] btrfs: make extent_write_locked_range() to be subpage compatible Qu Wenruo
2021-07-05 12:43   ` Qu Wenruo
2021-06-23  5:55 ` [PATCH RFC 8/8] btrfs: only allow subpage compression if the range fully covers the first page Qu Wenruo
2021-06-23 21:23 ` [PATCH RFC 0/8] btrfs: experimental compression support for subpage David Sterba
2021-06-24  1:10   ` Qu Wenruo
2021-06-23 22:37 ` David Sterba
2021-06-23 22:54   ` Qu Wenruo [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=860ea877-1986-c6c6-625f-ea3e2224c676@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    /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.