public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: "Marek Behún" <kabel@kernel.org>, "Qu Wenruo" <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, u-boot@lists.denx.de,
	"Dominique Martinet" <dominique.martinet@atmark-techno.com>
Subject: Re: [PATCH U-BOOT 2/3] btrfs: btrfs_file_read: allow opportunistic read until the end
Date: Tue, 18 Apr 2023 12:53:35 +0900	[thread overview]
Message-ID: <ZD4UP8oqlU0sP6Tt@codewreck.org> (raw)
In-Reply-To: <58fdd612-d2ac-1a77-25e5-59e8f7b668a2@gmx.com>

Qu Wenruo wrote on Tue, Apr 18, 2023 at 11:21:00AM +0800:
> > No, was just thinking the leading part being a separate loop doesn't
> > seem to make sense either as the code shouldn't care about sector size
> > alignemnt but about full extents.
> 
> The main concern related to the leading unaligned part is, we need to skip
> something unaligned from the beginning , while all other situations never
> need to skip such case (they at most skip the tailing part).

Ok, there is one exception for inline extents apparently.. But I'm not
still not convinced the `aligned_start != file_offset` check is enough
for that either; I'd say it's unlikely but the inline part can be
compressed, so we could have a file which has > 4k (sectorsize) of
expanded data, so a read from the 4k offset would skip the special
handling and fail (reading the whole extent in dest)

Even if that's not possible, reading just the first 10 bytes of an
inline extent will be aligned and go through the main loop which just
reads the whole extent, so it'll need the same handling as the regular
btrfs_read_extent_reg handling at which point it might just as well
handle start offset too.


That aside taking the loop in order:
- lookup_data_extent doesn't care (used in heading/tail)
- skipping holes don't care as they explicitely put cursor at start of
next extent (or bail out if nothing next)
- inline needs fixing anyway as said above
- PREALLOC or nothing on disk also goes straight to next and is ok
- ah, I see what you meant now, we need to substract the current
position within the extent to extent_num_bytes...
That's also already a problem, though; to take the same example:
0                 8k           16k
[extent1          | extent2 ... ]
reading from 4k onwards will try to read
min(extent_num_bytes, end-cur) = min(8k, 12k) = 8k
from the 4k offset which goes over the end of the extent.

That could actually be my resets from the previous mail.


So either the first check should just lookup the extent and check that
extent start matches current offset instead of checking for sectorsize
alignment, or we can just fix the loop and remove the first if.

-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2023-04-18 14:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18  1:17 [PATCH U-BOOT 0/3] btrfs: fix and improve read code Dominique Martinet
2023-04-18  1:17 ` [PATCH U-BOOT 1/3] btrfs: fix offset within btrfs_read_extent_reg() Dominique Martinet
2023-04-18  1:58   ` Qu Wenruo
2023-04-18  2:05     ` Dominique Martinet
2023-04-18  2:16       ` Qu Wenruo
2023-04-18  2:20       ` Qu Wenruo
2023-04-18  1:17 ` [PATCH U-BOOT 2/3] btrfs: btrfs_file_read: allow opportunistic read until the end Dominique Martinet
2023-04-18  2:02   ` Qu Wenruo
2023-04-18  2:41     ` Dominique Martinet
2023-04-18  2:53       ` Qu Wenruo
2023-04-18  3:07         ` Dominique Martinet
2023-04-18  3:21           ` Qu Wenruo
2023-04-18  3:53             ` Dominique Martinet [this message]
2023-04-18  5:17               ` Dominique Martinet
2023-04-18  7:15               ` Qu Wenruo
2023-04-18  1:17 ` [PATCH U-BOOT 3/3] btrfs: btfs_file_read: zero trailing data if no extent was found Dominique Martinet
2023-04-18  2:04   ` Qu Wenruo
2023-04-18  2:43     ` Dominique Martinet

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=ZD4UP8oqlU0sP6Tt@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=dominique.martinet@atmark-techno.com \
    --cc=kabel@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=u-boot@lists.denx.de \
    --cc=wqu@suse.com \
    /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