From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC] btrfs-progs: receive: fallback to buffered copy if clone failed
Date: Wed, 29 Sep 2021 07:51:59 +0800 [thread overview]
Message-ID: <20210928235159.9440-1-wqu@suse.com> (raw)
[BUG]
There are two every basic send streams:
(a/m/ctime and uuid omitted)
Stream 1: (Parent subvolume)
subvol ./parent_subv transid=8
chown ./parent_subv/ gid=0 uid=0
chmod ./parent_subv/ mode=755
utimes ./parent_subv/
mkfile ./parent_subv/o257-7-0
rename ./parent_subv/o257-7-0 dest=./parent_subv/source
utimes ./parent_subv/
write ./parent_subv/source offset=0 len=16384
chown ./parent_subv/source gid=0 uid=0
chmod ./parent_subv/source mode=600
utimes ./parent_subv/source
Stream 2: (snapshot and clone)
snapshot ./dest_subv transid=14 parent_transid=10
utimes ./dest_subv/
mkfile ./dest_subv/o258-14-0
rename ./dest_subv/o258-14-0 dest=./dest_subv/reflink
utimes ./dest_subv/
clone ./dest_subv/reflink offset=0 len=16384 from=./dest_subv/source clone_offset=0
chown ./dest_subv/reflink gid=0 uid=0
chmod ./dest_subv/reflink mode=600
utimes ./dest_subv/reflink
But if we receive the first stream with default mount options, then
remount to nodatasum, and try to receive the second stream, it will fail:
# mount /mnt/btrfs
# btrfs receive -f ~/parent_stream /mnt/btrfs/
At subvol parent_subv
# mount -o remount,nodatasum /mnt/btrfs
# btrfs receive -f ~/clone_stream /mnt/btrfs/
At snapshot dest_subv
ERROR: failed to clone extents to reflink: Invalid argument
# echo $?
1
[CAUSE]
Btrfs doesn't allow clone source and destination to have different NODATASUM
flags.
This is to prevent a data extent to be owned by both NODATASUM inode and
regular DATASUM inode.
For above receive operations, the clone destination is inheriting the
NODATASUM flag from mount option, while the clone source has no
NODATASUM flag, thus preventing us from doing the clone.
[FIX]
Btrfs send/receive doesn't require the underlying inode has the same
flags (thus we can send from compressed extent and receive on a
non-compressed filesystem).
So here we can just fall back to buffered write to copy the data from
the source file if we got an -EINVAL error.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
Reason for RFC:
Such fallback can lead to hidden bugs not being exposed, thus a new
warning is added for such fallback case.
Personally I really want to do more comprehensive check in user space to
ensure it's only mismatching NODATASUM flags causing the problem.
Then we can completely remove the warning message.
But unfortunately that check can go out-of-sync with kernel and due to
the lack of NODATASUM flags interface we're not really able to check
that easily.
So I took the advice from Filipe to just do a simple fall back.
Any feedback on such maybe niche point would help.
(Really hope it's me being paranoid again)
---
cmds/receive.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/cmds/receive.c b/cmds/receive.c
index 48c774cea587..4cb857a13cdf 100644
--- a/cmds/receive.c
+++ b/cmds/receive.c
@@ -705,6 +705,51 @@ out:
return ret;
}
+#define BUFFER_SIZE SZ_32K
+static int buffered_copy(int src_fd, int dst_fd, u64 src_offset, u64 len,
+ u64 dest_offset)
+{
+ unsigned char *buf;
+ u64 cur_offset = 0;
+ int ret = 0;
+
+ buf = calloc(BUFFER_SIZE, 1);
+ if (!buf)
+ return -ENOMEM;
+
+ while (cur_offset < len) {
+ u32 copy_len = min_t(u32, BUFFER_SIZE, len - cur_offset);
+ u32 write_offset = 0;
+ ssize_t read_size;
+
+ read_size = pread(src_fd, buf, copy_len, src_offset + cur_offset);
+ if (read_size < 0) {
+ ret = -errno;
+ error("failed to read source file: %m");
+ goto out;
+ }
+
+ /* Write the buffer to dest file */
+ while (write_offset < read_size) {
+ ssize_t write_size;
+
+ write_size = pwrite(dst_fd, buf + write_offset,
+ read_size - write_offset,
+ dest_offset + cur_offset + write_offset);
+ if (write_size < 0) {
+ ret = -errno;
+ error("failed to write source file: %m");
+ goto out;
+ }
+ write_offset += write_size;
+ }
+ cur_offset += read_size;
+ }
+out:
+ free(buf);
+ return ret;
+}
+
static int process_clone(const char *path, u64 offset, u64 len,
const u8 *clone_uuid, u64 clone_ctransid,
const char *clone_path, u64 clone_offset,
@@ -788,8 +833,16 @@ static int process_clone(const char *path, u64 offset, u64 len,
ret = ioctl(rctx->write_fd, BTRFS_IOC_CLONE_RANGE, &clone_args);
if (ret < 0) {
ret = -errno;
- error("failed to clone extents to %s: %m", path);
- goto out;
+ if (ret != -EINVAL) {
+ error("failed to clone extents to %s: %m", path);
+ goto out;
+ }
+
+ warning(
+ "failed to clone extents to %s, fallback to buffered write",
+ path);
+ ret = buffered_copy(clone_fd, rctx->write_fd, clone_offset,
+ len, offset);
}
out:
--
2.33.0
next reply other threads:[~2021-09-28 23:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 23:51 Qu Wenruo [this message]
2021-09-29 9:27 ` [PATCH RFC] btrfs-progs: receive: fallback to buffered copy if clone failed Filipe Manana
2021-09-29 9:33 ` Qu Wenruo
2021-09-29 9:59 ` Filipe Manana
2021-09-29 10:25 ` Qu Wenruo
2021-09-29 10:44 ` Filipe Manana
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=20210928235159.9440-1-wqu@suse.com \
--to=wqu@suse.com \
--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