From: Omar Sandoval <osandov@osandov.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v11 06/10] btrfs-progs: receive: encoded_write fallback to explicit decode and write
Date: Thu, 21 Oct 2021 10:22:50 -0700 [thread overview]
Message-ID: <YXGh6g4RGvlvj/29@relinquished.localdomain> (raw)
In-Reply-To: <8ac98c8e-901e-0fc1-2281-27d282486a49@suse.com>
On Thu, Oct 21, 2021 at 04:55:19PM +0300, Nikolay Borisov wrote:
>
>
> On 1.09.21 г. 20:01, Omar Sandoval wrote:
> > From: Boris Burkov <boris@bur.io>
> >
> > +static int decompress_lzo(const char *encoded_data, u64 encoded_len,
> > + char *unencoded_data, u64 unencoded_len,
> > + unsigned int page_size)
> > +{
> > + uint32_t total_len;
> > + size_t in_pos, out_pos;
> > +
> > + if (encoded_len < 4) {
> > + error("lzo header is truncated");
> > + return -EIO;
> > + }
> > + memcpy(&total_len, encoded_data, 4);
> > + total_len = le32toh(total_len);
> > + if (total_len > encoded_len) {
> > + error("lzo header is invalid");
> > + return -EIO;
> > + }
> > +
> > + in_pos = 4;
> > + out_pos = 0;
> > + while (in_pos < total_len && out_pos < unencoded_len) {
> > + size_t page_remaining;
> > + uint32_t src_len;
> > + lzo_uint dst_len;
> > + int ret;
> > +
> > + page_remaining = -in_pos % page_size;
>
> Why the -in_pos?
in_pos is our position in the encoded data. This calculates how many
bytes are remaining in the page that in_pos current points to.
> > + if (page_remaining < 4) {
> > + if (total_len - in_pos <= page_remaining)
> > + break;
> > + in_pos += page_remaining;
> > + }
> > +
> > + if (total_len - in_pos < 4) {
> > + error("lzo segment header is truncated");
> > + return -EIO;
> > + }
> > +
> > + memcpy(&src_len, encoded_data + in_pos, 4);
> > + src_len = le32toh(src_len);
> > + in_pos += 4;
> > + if (src_len > total_len - in_pos) {
> > + error("lzo segment header is invalid");
> > + return -EIO;
> > + }
> > +
> > + dst_len = page_size;
> > + ret = lzo1x_decompress_safe((void *)(encoded_data + in_pos),
> > + src_len,
> > + (void *)(unencoded_data + out_pos),
> > + &dst_len, NULL);
> > + if (ret != LZO_E_OK) {
> > + error("lzo1x_decompress_safe failed: %d", ret);
> > + return -EIO;
> > + }
> > +
> > + in_pos += src_len;
> > + out_pos += dst_len;
> > + }
> > + return 0;
> > +}
> > +
> > +static int decompress_and_write(struct btrfs_receive *rctx,
> > + const char *encoded_data, u64 offset,
> > + u64 encoded_len, u64 unencoded_file_len,
> > + u64 unencoded_len, u64 unencoded_offset,
> > + u32 compression)
> > +{
> > + int ret = 0;
> > + size_t pos;
> > + ssize_t w;
> > + char *unencoded_data;
> > + int page_shift;
> > +
> > + unencoded_data = calloc(unencoded_len, 1);
> > + if (!unencoded_data) {
> > + error("allocating space for unencoded data failed: %m");
> > + return -errno;
> > + }
> > +
> > + switch (compression) {
> > + case BTRFS_ENCODED_IO_COMPRESSION_ZLIB:
> > + ret = decompress_zlib(rctx, encoded_data, encoded_len,
> > + unencoded_data, unencoded_len);
> > + if (ret)
> > + goto out;
> > + break;
> > + case BTRFS_ENCODED_IO_COMPRESSION_ZSTD:
> > + ret = decompress_zstd(rctx, encoded_data, encoded_len,
> > + unencoded_data, unencoded_len);
> > + if (ret)
> > + goto out;
> > + break;
> > + case BTRFS_ENCODED_IO_COMPRESSION_LZO_4K:
> > + case BTRFS_ENCODED_IO_COMPRESSION_LZO_8K:
> > + case BTRFS_ENCODED_IO_COMPRESSION_LZO_16K:
> > + case BTRFS_ENCODED_IO_COMPRESSION_LZO_32K:
> > + case BTRFS_ENCODED_IO_COMPRESSION_LZO_64K:
> > + page_shift = compression - BTRFS_ENCODED_IO_COMPRESSION_LZO_4K + 12;
>
> Doesn't this calculation assume page size is 4k, what about arches with
> larger page size (ppc/aarch64), shouldn't that '12' be adjusted?
This is unrelated to the machine page size. It is translating the
BTRFS_ENCODED_IO_COMPRESSION_LZO_* value to the page size used for
compressing the data:
compression | - LZO_4K | + 12 | 1 <<
=====================================
LZO_4K = 3 | 0 | 12 | 4096
LZO_8K = 4 | 1 | 13 | 8192
LZO_16K = 5 | 2 | 14 | 16384
LZO_32K = 6 | 3 | 15 | 32768
LZO_64K = 7 | 4 | 16 | 65536
I'll fix the other comments, thanks.
next prev parent reply other threads:[~2021-10-21 17:22 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-01 17:00 [PATCH v11 00/14] btrfs: add ioctls and send/receive support for reading/writing compressed data Omar Sandoval
2021-09-01 17:00 ` [PATCH v11 01/14] fs: export rw_verify_area() Omar Sandoval
2021-11-18 19:19 ` Omar Sandoval
2022-01-04 19:06 ` Omar Sandoval
2021-09-01 17:00 ` [PATCH v11 02/14] fs: export variant of generic_write_checks without iov_iter Omar Sandoval
2021-10-14 12:03 ` Nikolay Borisov
2021-09-01 17:00 ` [PATCH v11 03/14] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2021-10-14 12:05 ` Nikolay Borisov
2021-10-18 18:09 ` Omar Sandoval
2021-09-01 17:00 ` [PATCH v11 04/14] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2021-10-21 12:44 ` Nikolay Borisov
2021-10-21 16:55 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 05/14] btrfs: support different disk extent size for delalloc Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 06/14] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2021-10-14 12:54 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 07/14] btrfs: add definitions + documentation for encoded I/O ioctls Omar Sandoval
2021-10-15 9:42 ` Nikolay Borisov
2021-10-18 18:16 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 08/14] btrfs: add BTRFS_IOC_ENCODED_READ Omar Sandoval
2021-10-15 11:45 ` Nikolay Borisov
2021-10-18 23:59 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 09/14] btrfs: add BTRFS_IOC_ENCODED_WRITE Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 10/14] btrfs: add send stream v2 definitions Omar Sandoval
2021-10-18 12:46 ` Nikolay Borisov
2021-10-18 15:11 ` Nikolay Borisov
2021-10-18 18:58 ` Omar Sandoval
2021-10-19 7:01 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 11/14] btrfs: send: write larger chunks when using stream v2 Omar Sandoval
2021-10-18 12:57 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 12/14] btrfs: send: allocate send buffer with alloc_page() and vmap() for v2 Omar Sandoval
2021-10-18 11:10 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 13/14] btrfs: send: send compressed extents with encoded writes Omar Sandoval
2021-10-18 11:59 ` Nikolay Borisov
2021-10-19 0:11 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 14/14] btrfs: send: enable support for stream v2 and compressed writes Omar Sandoval
2021-10-18 12:44 ` Nikolay Borisov
2021-10-18 18:34 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 01/10] btrfs-progs: receive: support v2 send stream larger tlv_len Omar Sandoval
2021-10-20 13:49 ` Nikolay Borisov
2021-10-20 18:48 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 02/10] btrfs-progs: receive: dynamically allocate sctx->read_buf Omar Sandoval
2021-10-20 14:09 ` Nikolay Borisov
2021-10-20 14:35 ` Nikolay Borisov
2021-10-20 17:44 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 03/10] btrfs-progs: receive: support v2 send stream DATA tlv format Omar Sandoval
2021-10-20 14:36 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 04/10] btrfs-progs: receive: add send stream v2 cmds and attrs to send.h Omar Sandoval
2021-10-20 14:38 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 05/10] btrfs-progs: receive: process encoded_write commands Omar Sandoval
2021-10-21 13:33 ` Nikolay Borisov
2021-10-21 16:52 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 06/10] btrfs-progs: receive: encoded_write fallback to explicit decode and write Omar Sandoval
2021-10-21 13:55 ` Nikolay Borisov
2021-10-21 17:22 ` Omar Sandoval [this message]
2021-09-01 17:01 ` [PATCH v11 07/10] btrfs-progs: receive: process fallocate commands Omar Sandoval
2021-10-21 14:21 ` Nikolay Borisov
2021-10-21 17:28 ` Omar Sandoval
2021-09-01 17:01 ` [PATCH v11 08/10] btrfs-progs: receive: process setflags ioctl commands Omar Sandoval
2021-10-21 14:22 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 09/10] btrfs-progs: send: stream v2 ioctl flags Omar Sandoval
2021-10-22 6:35 ` Nikolay Borisov
2021-09-01 17:01 ` [PATCH v11 10/10] btrfs-progs: receive: add tests for basic encoded_write send/receive Omar Sandoval
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=YXGh6g4RGvlvj/29@relinquished.localdomain \
--to=osandov@osandov.com \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nborisov@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