> 64kiB is the _maximum_ block size used. Theoretically, mkifs should check the 
> output size of each LZO block right after the compression step, and if the 
> output length exceeds 0x10000, reduce the input length and retry. Hence, the 
> resulting IFS should never contain an LZO block larger than 64kiB and the 16-
> bit block size should always be sufficient.
> 
> Is this an actual issue with a compressed IFS generated by mkifs, or merely 
> theoretical? If it's an actual issue, can you provide a test case (build file 
> + all files included in image)?
> 
> Kind regards,
> Thomas

Thanks for your reply! I can reproduce some lengh list of compressed blocks now.
Yes. I checked your 'theoretical reducing', that's true. Here is what mkifs doing:
> block = lzo.compress(bytes(data[i : i + block_size]), level, False)
> if len(block) >= max_block:
>     bs = block_size - int(max_block / 16)
>     block = lzo.compress(bytes(data[i : i + bs]), level, False)
>     blocks.append(struct.pack(head_fmt, len(block)) + block)
>     block = lzo.compress(bytes(data[i + bs: i + block_size]), level, False)
So this is just a theoretical issue.
And I can't post whole build and image files here since they are commercial productions.
Thanks again!

Actually I miss remembered, it's actually 64KB.

The input block size for LZO compression is 64KiB.