From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: zlang@redhat.com, fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 3/4] xfs/259: try to force loop device block size
Date: Tue, 3 Jun 2025 07:36:34 -0700 [thread overview]
Message-ID: <20250603143634.GG8303@frogsfrogsfrogs> (raw)
In-Reply-To: <aD0xdHHKmfLmAOXb@infradead.org>
On Sun, Jun 01, 2025 at 10:07:00PM -0700, Christoph Hellwig wrote:
> On Wed, May 28, 2025 at 03:22:26PM -0700, Darrick J. Wong wrote:
> > Welll... the only reason I patched the loop driver to turn ovn directio
> > by default is because writeback throttling for loop devices keeps
> > getting turned on and off randomly. At this point I have NFI if
> > throttling is actually the desired behavior or not. It makes fstests
> > crawl really slowly.
> >
> > On one hand it seems bogus that a loopbacked filesystem with enough
> > dirty pages to trip the thresholds then gets throttled doing writeback
> > to the pagecache of the loop file, but OTOH it /is/ more dirty
> > pagecache. Ultimately I think non-directio loop devices are stupid
> > especially when there are filesystems on top of them, but I bet there's
> > some user that would break if we suddenly started requiring directio
> > alignments.
> >
> > Maybe RWF_DONTCACHE will solve this whenever it stabilizes.
>
> Well, I'm all for using direct I/O loop devices by default. But having
> non-standard kernel hacks for that is pretty silly. Can we just make
> xfstests use direct I/O by default so that everyone uses the same
> configuration?
I guess we could just modify _create_loop_device to set directio from
creation and fall back to pagecache io if need be, instead of the weird
"create it then try to change the mode" dance that we do now. Does that
sound better?
--D
next prev parent reply other threads:[~2025-06-03 14:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-21 22:40 [PATCHSET 1/2] fstests: check new 6.15 behaviors Darrick J. Wong
2025-05-21 22:41 ` [PATCH 1/4] xfs/273: fix test for internal zoned filesystems Darrick J. Wong
2025-05-23 5:17 ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 2/4] xfs/259: drop the 512-byte fsblock logic from this test Darrick J. Wong
2025-05-23 5:17 ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 3/4] xfs/259: try to force loop device block size Darrick J. Wong
2025-05-22 1:21 ` Dave Chinner
2025-05-28 22:36 ` Darrick J. Wong
2025-05-23 5:19 ` Christoph Hellwig
2025-05-28 22:22 ` Darrick J. Wong
2025-06-02 5:07 ` Christoph Hellwig
2025-06-03 14:36 ` Darrick J. Wong [this message]
2025-06-03 14:37 ` Christoph Hellwig
2025-05-21 22:41 ` [PATCH 4/4] xfs/432: fix metadump loop device blocksize problems Darrick J. Wong
2025-05-22 1:08 ` Dave Chinner
2025-05-28 22:37 ` Darrick J. Wong
2025-07-10 16:16 ` [PATCHSET 1/2] fstests: check new 6.15 behaviors Darrick J. Wong
2025-07-10 18:26 ` Zorro Lang
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=20250603143634.GG8303@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.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.