On 2018年05月22日 22:00, David Sterba wrote: > On Mon, May 21, 2018 at 01:19:25PM +0800, Qu Wenruo wrote: >> Although it's not that complex, but such comment could still save >> several minutes for newer reader/reviewer. >> >> Signed-off-by: Qu Wenruo <w...@suse.com> >> --- >> fs/btrfs/lzo.c | 23 +++++++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> >> diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c >> index 0667ea07f766..d0c6789ff78f 100644 >> --- a/fs/btrfs/lzo.c >> +++ b/fs/btrfs/lzo.c >> @@ -17,6 +17,29 @@ >> >> #define LZO_LEN 4 >> >> +/* >> + * Btrfs LZO compression format >> + * >> + * Regular LZO compressed data extent consists of: >> + * 1. Header >> + * Fixed size. LZO_LEN (4) bytes long, LE32. >> + * Records the total size (*includes* the header) of real compressed >> data. >> + * >> + * 2. Segment(s) >> + * Variable size. Includes one segment header, and then data payload. >> + * One regular LZO compressed extent can have one or more segments. >> + * >> + * 2.1 Segment header >> + * Fixed size. LZO_LEN (4) bytes long, LE32. >> + * Records the total size of the segment (*excludes* the header). >> + * >> + * 2.2 Data Payload >> + * Variable size. Size up limit should be >> lzo1x_worst_compress(PAGE_SIZE). >> + * >> + * While for inlined LZO compressed data extent, it doesn't have Header, >> just >> + * *ONE* Segment. > > It does have header that has the same value as the 1st segment header so > it's skipped.
Indeed, I just missed the first "data_in += LZO_LEN;" line. And in that case, the header should also be checked. > > There's also one catch in the format that if there's a less then 4 bytes > left to the page size, the new segment starts on the new page. I'll also update the patch to reflect this. Thanks, Qu > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
signature.asc
Description: OpenPGP digital signature
