From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Anand Jain <anand.jain@oracle.com>,
dsterba@suse.cz, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: inode: Don't compress if NODATASUM or NODATACOW set
Date: Fri, 28 Jun 2019 13:58:37 +0800 [thread overview]
Message-ID: <4581937c-cfa1-91e2-7a83-7c3f40f02857@gmx.com> (raw)
In-Reply-To: <fa804a25-b0a8-ad1d-760a-bf543418970a@oracle.com>
[-- Attachment #1.1: Type: text/plain, Size: 1897 bytes --]
On 2019/6/28 上午10:47, Anand Jain wrote:
> On 27/6/19 10:58 PM, David Sterba wrote:
>> On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
>>> Ping?
>>>
>>> This patch should fix the problem of compressed extent even when
>>> nodatasum is set.
>>>
>>> It has been one year but we still didn't get a conclusion on where
>>> force_compress should behave.
>>
>> Note that pings to patches sent year ago will get lost, I noticed only
>> because you resent it and I remembered that we had some discussions,
>> without conclusions.
>>
>>> But at least to me, NODATASUM is a strong exclusion for compress, no
>>> matter whatever option we use, we should NEVER compress data without
>>> datasum/datacow.
>>
>> That's correct,
>
> But I wonder what's the reason that datasum/datacow is prerequisite for
> the compression ?
It's easy to understand the hard requirement for data COW.
If you overwrite compressed extent, a powerloss before transaction
commit could easily screw up the data.
Furthermore, what will happen if you're overwriting a 16K data extent
while its original compressed size is only 4K, while the new data after
compression is 8K?
For checksum, I'd say it's not as a hard requirement as data cow, but
still a very preferred one.
Since compressed data corruption could cause more problem, e.g. one bit
corruption can cause the whole extent to be corrupted, it's highly
recommended to have checksum to protect them.
Thanks,
Qu
>
> Thanks, Anand
>
>> but the way you fix it is IMO not right. This was also
>> noticed by Nikolay, that there are 2 locations that call
>> inode_need_compress but with different semantics.
>>
>> One is the decision if compression applies at all, and the second one
>> when that's certain it's compression, to do it or not based on the
>> status decision of eg. heuristics.
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-06-28 5:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-15 7:36 [PATCH 0/2] btrfs: Enhance btrfs handling compression and Qu Wenruo
2018-05-15 7:36 ` [PATCH 1/2] btrfs: inode: Don't compress if NODATASUM or NODATACOW set Qu Wenruo
2018-05-15 8:21 ` Nikolay Borisov
2018-05-15 8:30 ` Qu Wenruo
2018-05-15 8:35 ` Nikolay Borisov
2018-05-15 8:48 ` Qu Wenruo
2018-05-15 10:36 ` Nikolay Borisov
2018-05-15 10:48 ` Qu Wenruo
2019-06-25 8:24 ` Qu Wenruo
2019-06-27 14:58 ` David Sterba
2019-06-28 1:26 ` Qu Wenruo
2019-06-28 11:34 ` David Sterba
2019-06-28 12:09 ` Qu Wenruo
2019-06-28 16:38 ` David Sterba
2019-06-28 2:47 ` Anand Jain
2019-06-28 5:58 ` Qu Wenruo [this message]
2019-06-28 6:56 ` Anand Jain
2019-06-28 7:09 ` Qu Wenruo
2018-05-15 7:36 ` [PATCH 2/2] btrfs: lzo: Avoid decompressing obviously corrupted data Qu Wenruo
2018-05-15 8:05 ` Nikolay Borisov
2018-05-15 8:32 ` Qu Wenruo
2018-05-15 8:34 ` Nikolay Borisov
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=4581937c-cfa1-91e2-7a83-7c3f40f02857@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=anand.jain@oracle.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).