From: Christoph Hellwig <hch@infradead.org>
To: Filipe Manana <fdmanana@kernel.org>
Cc: Boris Burkov <boris@bur.io>,
Chris Murphy <chris@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: LMDB mdb_copy produces a corrupt database on btrfs, but not on ext4
Date: Thu, 16 Feb 2023 10:49:20 -0800 [thread overview]
Message-ID: <Y+56sPyNHZRVQdnj@infradead.org> (raw)
In-Reply-To: <CAL3q7H4CmQOG6wYBg8Ha0xUJ+QWKEfF8YixJ-DwnJy=fXs9e=Q@mail.gmail.com>
On Thu, Feb 16, 2023 at 06:00:08PM +0000, Filipe Manana wrote:
> Ok, so the problem is btrfs_dio_iomap_end() detects the submitted
> amount is less than expected, so it marks the ordered extents as not
> up to date, setting the BTRFS_ORDERED_IOERR bit on it.
> That results in having an unexpected hole for the range [8192, 65535],
> and no error returned to btrfs_direct_write().
>
> My initial thought was to truncate the ordered extent at
> btrfs_dio_iomap_end(), similar to what we do at
> btrfs_invalidate_folio().
> I think that should work, however we would end up with a bookend
> extent (but so does your proposed fix), but I don't see an easy way to
> get around that.
Wouldn't a better way to handle this be to cache the ordered_extent in
the btrfs_dio_data, and just reuse it on the next iteration if present
and covering the range?
next prev parent reply other threads:[~2023-02-16 18:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-15 20:04 LMDB mdb_copy produces a corrupt database on btrfs, but not on ext4 Chris Murphy
2023-02-15 20:16 ` Chris Murphy
2023-02-15 21:41 ` Filipe Manana
2023-02-15 23:21 ` Boris Burkov
2023-02-16 0:34 ` Boris Burkov
2023-02-16 1:46 ` Boris Burkov
2023-02-16 5:58 ` Christoph Hellwig
2023-02-16 9:30 ` Christoph Hellwig
2023-02-16 11:57 ` Filipe Manana
2023-02-16 17:14 ` Boris Burkov
2023-02-16 18:00 ` Filipe Manana
2023-02-16 18:49 ` Christoph Hellwig [this message]
2023-02-16 21:43 ` Filipe Manana
2023-02-16 22:45 ` Boris Burkov
2023-02-17 11:19 ` Filipe Manana
2023-02-16 10:05 ` Qu Wenruo
2023-02-16 12:01 ` Filipe Manana
2023-02-17 0:15 ` Qu Wenruo
2023-02-17 11:38 ` Filipe Manana
2023-04-05 13:07 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-04-06 15:47 ` David Sterba
2023-04-06 22:40 ` Neal Gompa
2023-04-07 6:10 ` Linux regression tracking (Thorsten Leemhuis)
2023-04-08 0:08 ` Boris Burkov
2023-04-11 19:27 ` David Sterba
2023-04-12 9:57 ` Linux regression tracking (Thorsten Leemhuis)
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=Y+56sPyNHZRVQdnj@infradead.org \
--to=hch@infradead.org \
--cc=boris@bur.io \
--cc=chris@colorremedies.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.