[PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero

Qu Wenruo
2020-03-24T11:03:45Z

On 2020/3/20 ??12:28, David Sterba wrote:
> On Thu, Mar 19, 2020 at 03:34:12PM +0100, Matthias Brugger wrote:
>>
>>
>> On 19/03/2020 14:56, David Sterba wrote:
>>> On Thu, Mar 19, 2020 at 02:33:28PM +0100, Matthias Brugger wrote:
>>>>> dlen -= out_len;
>>>>>
>>>>> res += out_len;
>>>>> +
>>>>> + /*
>>>>> + * If the 4 bytes header does not fit to the rest of the page we
>>>>> + * have to move to next one, or we read some garbage.
>>>>> + */
>>>>> + mod_page = tot_in % PAGE_SIZE;
>>>>
>>>> in U-Boot we use 4K page sizes, but the OS could use another page size (16K or
>>>> 64k). Would we need to adapt that code to reflect which page size is used on the
>>>> medium we want to access?
>>>
>>> Yes, it is the 'sectorsize' as it's set up in fs_info or it's equivalent
>>> in uboot. For kernel the page size == sectorsize is kind of implicit and
>>> verified at mount time.
>>>
>>
>> Does this mean we would need to add a Kconfig option to set the sectorsize in
>> U-Boot?
>
> No, the value depends on the filesystem so it can't be a config option.
> What I mean is btrfs_super_block::sectorsize, where the superblock is
> btrfs_info::sb.
>

Sorry for the delayed reply. (Stupid filter setup).

Currently most Uboot boards should use the same page size setup for its
kernel, and most btrfs uses 4K sector size.

So for Uboot it should be no problem.

Although the best practice is to read the fs_info::sectorsize as David
mentioned, but the code base doesn't allow us to do that yet.

So I'm going to backport the read part code from btrfs-progs in the
near-future, and completely solve it, making it sector size independent.

Would this plan look OK to you? Or we need to wait for the full
re-implementation?

Thanks,
Qu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200324/22e935bd/attachment.sig>