From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 0/6] Fix long standing -EOPNOTSUPP problem caused by large inline extent
Date: Thu, 22 Mar 2018 08:12:31 +0800 [thread overview]
Message-ID: <74866cc8-788b-233c-e52f-9ac413e5e6af@gmx.com> (raw)
In-Reply-To: <20180321155115.GT6955@twin.jikos.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2784 bytes --]
On 2018年03月21日 23:51, David Sterba wrote:
> On Tue, Mar 20, 2018 at 02:42:23PM +0800, Qu Wenruo wrote:
>> The patch is based on v4.15.1, and is designed to replace the old patch
>> in devel branch.
>>
>> Kernel doesn't support dropping range inside inline extent, and prevents
>> such thing happening by limiting max inline extent size to
>> min(max_inline, sectorsize - 1) in cow_file_range_inline().
>>
>> However btrfs-progs only inherit the BTRFS_MAX_INLINE_DATA_SIZE() macro,
>> which doesn't have sectorsize check.
>> And since btrfs-progs defaults to 16K nodesize, above macro allows large
>> inline extent over 15K size.
>>
>> This leads to unexpected kernel behavior.
>>
>> The bug exists in several parts of btrfs-progs, any tool which creates
>> file extent is involved, including:
>> 1) btrfs-convert
>> 2) mkfs --rootdir
>>
>> This patchset fixes the problems in convert (both ext2 and reiserfs),
>> mkfs --rootdir, then add check support for both original and lowmem
>> mode, and finally adds 2 test cases, one for mkfs and one for convert.
>>
>> For mkfs test case, it can already be exposed by misc/002, but a
>> pin-point test case will be much better.
>>
>> changelog:
>> v2:
>> Don't modify BTRFS_MAX_INLINE_DATA_SIZE(), but add extra check to
>> callers who create file extents.
>> v3:
>> Merge fixes for convert.
>> Add real commit message for convert fixes.
>> Use $TEST_TOP to replace cooperate with stand alone test cases.
>> Use for loops to make the new test case shorter.
>>
>> Qu Wenruo (6):
>> btrfs-progs: convert: Fix inline file extent creation condition
>> btrfs-progs: mkfs/rootdir: Fix inline extent creation check
>> btrfs-progs: check/original mode: Check inline extent size
>> btrfs-progs: check/lowmem mode: Check inline extent size
>> btrfs-progs: test/convert: Add test case for invalid large inline data
>> extent
>> btrfs-progs: test/mkfs: Add test case for rootdir inline extent size
>
> Applied, thanks. I had to fix the test, fallocate may fail, so a file of
> given size is created directly.
The fix looks good, and I learn a new trick.
But I'm wondering how could it fail.
Nowadays /tmp should be tmpfs created by systemd, which supports fallocate.
Or is the CI things doesn't follow this?
Thanks,
Qu
>
> I hope this bug is fixed. My plan was to release 4.15.2 with just
> bugfixes but as this took some time to fix, there likely will be no
> minor release before 4.16 as kernel is about to be released next week.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]
next prev parent reply other threads:[~2018-03-22 0:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 6:42 [PATCH v3 0/6] Fix long standing -EOPNOTSUPP problem caused by large inline extent Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 1/6] btrfs-progs: convert: Fix inline file extent creation condition Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 2/6] btrfs-progs: mkfs/rootdir: Fix inline extent creation check Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 3/6] btrfs-progs: check/original mode: Check inline extent size Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 4/6] btrfs-progs: check/lowmem " Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 5/6] btrfs-progs: test/convert: Add test case for invalid large inline data extent Qu Wenruo
2018-03-20 6:42 ` [PATCH v3 6/6] btrfs-progs: test/mkfs: Add test case for rootdir inline extent size Qu Wenruo
2018-03-21 15:51 ` [PATCH v3 0/6] Fix long standing -EOPNOTSUPP problem caused by large inline extent David Sterba
2018-03-22 0:12 ` Qu Wenruo [this message]
2018-03-22 13:24 ` David Sterba
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=74866cc8-788b-233c-e52f-9ac413e5e6af@gmx.com \
--to=quwenruo.btrfs@gmx.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).