From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz
Subject: [PATCH v3 1/6] btrfs-progs: convert: Fix inline file extent creation condition
Date: Tue, 20 Mar 2018 14:42:24 +0800 [thread overview]
Message-ID: <20180320064229.31493-2-wqu@suse.com> (raw)
In-Reply-To: <20180320064229.31493-1-wqu@suse.com>
[Bug]
On btrfs converted from ext*, one user reported the following kernel
warning:
------------[ cut here ]------------
BTRFS: Transaction aborted (error -95)
WARNING: CPU: 0 PID: 324 at fs/btrfs/inode.c:3042 btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
RIP: 0010:btrfs_finish_ordered_io+0x7ab/0x850 [btrfs]
...
Call Trace:
normal_work_helper+0x39/0x370 [btrfs]
process_one_work+0x1ce/0x410
worker_thread+0x2b/0x3d0
? process_one_work+0x410/0x410
kthread+0x113/0x130
? kthread_create_on_node+0x70/0x70
? do_syscall_64+0x74/0x190
? SyS_exit_group+0x10/0x10
ret_from_fork+0x35/0x40
---[ end trace c8ed62ff6a525901 ]---
BTRFS: error (device dm-2) in
btrfs_finish_ordered_io:3042: errno=-95 unknown
BTRFS info (device dm-2): forced readonly
BTRFS error (device dm-2): pending csums is 6447104
[Cause]
The call trace and the unique return value points to
__btrfs_drop_extents(), when we tries to drop pages of an inline extent,
we will trigger such -EOPNOTSUPP.
However kernel has limitation on the size of inline file extent
(sector size for ram size and sector size - 1for on-disk size),
btrfs-convert doesn't have the same limitation, resulting much larger
file extent.
The lack of correct inline extent size check dates back to 2008 when
btrfs-convert is added into btrfs-progs.
[Fix]
Fix the inline extent creation condition, not only using
BTRFS_MAX_INLINE_DATA_SIZE(), which is only the maximum size of inline
data according to nodesize, but also limit it against sector size.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
convert/source-ext2.c | 2 +-
convert/source-reiserfs.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/convert/source-ext2.c b/convert/source-ext2.c
index b1492c78693d..e13fbe00415a 100644
--- a/convert/source-ext2.c
+++ b/convert/source-ext2.c
@@ -310,7 +310,7 @@ static int ext2_create_file_extents(struct btrfs_trans_handle *trans,
if (ret)
goto fail;
if ((convert_flags & CONVERT_FLAG_INLINE_DATA) && data.first_block == 0
- && data.num_blocks > 0
+ && data.num_blocks > 0 && inode_size < sectorsize
&& inode_size <= BTRFS_MAX_INLINE_DATA_SIZE(root->fs_info)) {
u64 num_bytes = data.num_blocks * sectorsize;
u64 disk_bytenr = data.disk_block * sectorsize;
diff --git a/convert/source-reiserfs.c b/convert/source-reiserfs.c
index 39d6f0728bd3..eeb68d962c5d 100644
--- a/convert/source-reiserfs.c
+++ b/convert/source-reiserfs.c
@@ -376,7 +376,8 @@ static int reiserfs_convert_tail(struct btrfs_trans_handle *trans,
u64 isize;
int ret;
- if (length >= BTRFS_MAX_INLINE_DATA_SIZE(root->fs_info))
+ if (length >= BTRFS_MAX_INLINE_DATA_SIZE(root->fs_info) ||
+ length >= root->fs_info->sectorsize)
return convert_direct(trans, root, objectid, inode, body,
length, offset, convert_flags);
--
2.16.2
next prev parent reply other threads:[~2018-03-20 6:42 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 ` Qu Wenruo [this message]
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
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=20180320064229.31493-2-wqu@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 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).