From: Josef Bacik <josef@toxicpanda.com>
To: David Sterba <dsterba@suse.cz>
Cc: David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, Qu Wenruo <wqu@suse.com>
Subject: Re: [GIT PULL] Btrfs updates for 6.15
Date: Fri, 28 Mar 2025 15:39:27 -0400 [thread overview]
Message-ID: <20250328193927.GA1393046@perftesting> (raw)
In-Reply-To: <20250328173644.GG32661@twin.jikos.cz>
On Fri, Mar 28, 2025 at 06:36:44PM +0100, David Sterba wrote:
> On Fri, Mar 28, 2025 at 09:27:51AM -0400, Josef Bacik wrote:
> > On Mon, Mar 24, 2025 at 05:37:51PM +0100, David Sterba wrote:
> > > Hi,
> > >
> > > please pull the following btrfs updates, thanks.
> > >
> > > User visible changes:
> > >
> > > - fall back to buffered write if direct io is done on a file that requires
> > > checksums
> >
> > <trimming the everybody linux-btrfs from the cc list>
> >
> > What? We use this constantly in a bunch of places to avoid page cache overhead,
> > it's perfectly legitimate to do DIO to a file that requires checksums. Does the
> > vm case mess this up? Absolutely, but that's why we say use NOCOW for that
> > case. We've always had this behavior, we've always been clear that if you break
> > it you buy it. This is a huge regression for a pretty significant use case.
>
> The patch has been up for like 2 months and you could have said "don't
> because reasons" any time before the pull request. Now we're left with a
> revert, or other alternatives making the use cases working.
Boris told me about this and I forgot. I took everybody off the CC list because
I don't want to revert it, in fact generally speaking I'd love to never have
these style of bug reports again.
But it is a pretty significant change. Are we ok going forward saying you don't
get O_DIRECT unless you want NOCOW? Should we maybe allow for users to indicate
they're not dumb and can be trusted to do O_DIRECT properly? I just think this
opens us up to a lot more uncomfortable conversations than the other behavior.
I personally think this is better, if it's been sitting there for 2 months then
hooray we're in agreement. But I'm also worried it'll come back to bite us.
Thanks,
Josef
next prev parent reply other threads:[~2025-03-28 19:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 16:37 [GIT PULL] Btrfs updates for 6.15 David Sterba
2025-03-27 20:48 ` pr-tracker-bot
2025-03-28 13:27 ` Josef Bacik
2025-03-28 17:36 ` David Sterba
2025-03-28 19:39 ` Josef Bacik [this message]
2025-03-28 21:36 ` Qu Wenruo
2025-03-31 9:35 ` Daniel Vacek
2025-03-31 23:58 ` David Sterba
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=20250328193927.GA1393046@perftesting \
--to=josef@toxicpanda.com \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--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 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.