Decompression success/failure dependent on PAGE_SIZE?

Decompression success/failure dependent on PAGE_SIZE?

[Marek Behún]

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?

Thank you.

Marek

Re: Decompression success/failure dependent on PAGE_SIZE?

[Austin S. Hemmelgarn]

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.

Re: Decompression success/failure dependent on PAGE_SIZE?

[Nikolay Borisov]

On 29.08.2017 19: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?

Please have a look in btrfs_check_super_valid(), which is being called
from open_ctree, which in turn is called when a filesystem is mounted.

Currently btrfs supports a single blocksize value - PAGE_SIZE, also it's
forbidden to mount a filesystem on systems with different page_sizes.
When the sub-page blocksizes patch is merged this might be have to be
taken into consideration but certainly not at present times.

> 
> Thank you.
> 
> Marek
> --
> 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
>