public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: u-boot@lists.denx.de
Subject: [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero
Date: Tue, 24 Mar 2020 19:03:45 +0800	[thread overview]
Message-ID: <178a0729-57ad-030d-7bbb-e3afb0278d57@gmx.com> (raw)
In-Reply-To: <20200319162822.GG12659@twin.jikos.cz>



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>

  parent reply	other threads:[~2020-03-24 11:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-19 12:30 [PATCH 0/2] uboot: fs/btrfs: Fix read error on LZO compressed extents Qu Wenruo
2020-03-19 12:30 ` [PATCH 1/2] uboot: fs/btrfs: Use LZO_LEN to replace immediate number Qu Wenruo
2020-03-19 12:30 ` [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero Qu Wenruo
2020-03-19 13:33   ` Matthias Brugger
2020-03-19 13:56     ` David Sterba
2020-03-19 14:34       ` Matthias Brugger
2020-03-19 16:28         ` David Sterba
2020-03-24 11:03           ` Qu Wenruo
2020-03-25  7:58             ` Marek Behun
2020-03-24 11:03           ` Qu Wenruo [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-03-19 12:33 [PATCH 0/2] uboot: fs/btrfs: Fix read error on LZO compressed extents Qu Wenruo
2020-03-19 12:33 ` [PATCH 2/2] uboot: fs/btrfs: Fix LZO false decompression error caused by pending zero Qu Wenruo
2020-03-25  8:09   ` Marek Behun
2020-03-25  8:27     ` Qu Wenruo
2020-03-25 11:00       ` Marek Behun
2020-03-25 11:10         ` Marek Behun
2020-03-25 11:32         ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=178a0729-57ad-030d-7bbb-e3afb0278d57@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox