On Fri, Jun 11, 2021 at 12:58:58PM +0000, Chris Mason wrote: > > On Jun 10, 2021, at 12:20 PM, David Sterba <dste...@suse.cz> wrote: > > On Thu, Jun 10, 2021 at 04:50:09PM +0200, Christophe Leroy wrote: > >> Le 10/06/2021 à 15:54, Chris Mason a écrit : > >>>> On Jun 10, 2021, at 1:23 AM, Christophe Leroy > >>>> <christophe.le...@csgroup.eu> 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 }