On Fri, Jun 11, 2021 at 12:58:58PM +0000, Chris Mason wrote:

quoted

On Jun 10, 2021, at 12:20 PM, David Sterba [off-list ref] wrote:
On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote:

quoted

Le 10/06/2021 à 15:54, Chris Mason a écrit :

quoted

quoted

On Jun 10, 2021, at 1:23 AM, Christophe Leroy [off-list ref] wrote:

And there's no such thing like "just bump BTRFS_MAX_COMPRESSED to 256K".
The constant is part of on-disk format for lzo and otherwise changing it
would impact performance so this would need proper evaluation.

Sorry, how is it baked into LZO?  It definitely will have performance implications, I agree there.

lzo_decompress_bio:

309         /*
310          * Compressed data header check.
311          *
312          * The real compressed size can't exceed the maximum extent length, and
313          * all pages should be used (whole unused page with just the segment
314          * header is not possible).  If this happens it means the compressed
315          * extent is corrupted.
316          */
317         if (tot_len > min_t(size_t, BTRFS_MAX_COMPRESSED, srclen) ||
318             tot_len < srclen - PAGE_SIZE) {
319                 ret = -EUCLEAN;
320                 goto done;
321         }