From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Marek Behún" <marek.behun@nic.cz>, linux-btrfs@vger.kernel.org
Subject: Re: Decompression success/failure dependent on PAGE_SIZE?
Date: Tue, 29 Aug 2017 13:13:18 -0400 [thread overview]
Message-ID: <974aff07-4549-1a7f-be13-e8a6ec6e16f2@gmail.com> (raw)
In-Reply-To: <20170829184342.2f6ec0b0@dellmb.labs.office.nic.cz>
On 2017-08-29 12:43, Marek Behún wrote:
> Hello,
>
> so I've been studying the linux btrfs code and have come across this:
>
> in inode.c function uncompress_inline the max_size size variable is set
> to min(max_size, PAGE_SIZE) and only max_size of output data are
> decompressed.
>
> The code for compression (in lzo.c for example) uses PAGE_SIZEd chunks
> to compress an inline extent.
>
> If I understand it correctly, then if the filesystem is created and used
> on a computer with PAGE_SIZE for example 16KB, and an extent of size
> 16KB is compressed to (for example 9KB) and stored as inline extent,
> and then the filesystem is mounted on a computer with PAGE_SIZE = 4KB,
> reading the extent will result in a failure or incomplete read.
>
> Is this a bug, or is this behaviour a feature?
It's absolutely not a feature. I've not actually seen this issue
mentioned anywhere myself, but I'm willing to bet that the consensus
among developers will be that its an unintentional limitation of the
current design. There are in fact issues when trying to use a
filesystem with a block size smaller than PAGE_SIZE as well, so the
general consensus is to not mix filesystems from different architectures
unless you know the page size matches.
next prev parent reply other threads:[~2017-08-29 17:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-29 16:43 Decompression success/failure dependent on PAGE_SIZE? Marek Behún
2017-08-29 17:13 ` Austin S. Hemmelgarn [this message]
2017-08-29 17:44 ` 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=974aff07-4549-1a7f-be13-e8a6ec6e16f2@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=marek.behun@nic.cz \
/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).