All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.