From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>, Stefan Roesch <shr@fb.com>,
io-uring@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-block@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 04/13] fs: split off __alloc_page_buffers function
Date: Tue, 22 Feb 2022 00:18:35 -0800 [thread overview]
Message-ID: <YhScWzgGVyeaufvU@infradead.org> (raw)
In-Reply-To: <YhHCVnTYNPrtbu08@casper.infradead.org>
On Sun, Feb 20, 2022 at 04:23:50AM +0000, Matthew Wilcox wrote:
> On Fri, Feb 18, 2022 at 11:35:10PM -0800, Christoph Hellwig wrote:
> > Err, hell no. Please do not add any new functionality to the legacy
> > buffer head code. If you want new features do that on the
> > non-bufferhead iomap code path only please.
>
> I think "first convert the block device code from buffer_heads to iomap"
> might be a bit much of a prerequisite. I think running ext4 on top of a
> block device still requires buffer_heads, for example (I tried to convert
> the block device to use mpage in order to avoid creating buffer_heads
> when possible, and ext4 stopped working. I didn't try too hard to debug
> it as it was a bit of a distraction at the time).
Oh, I did not spot the users here is the block device. Which is really
weird, why would anyone do buffered writes to a block devices? Doing
so is a bit of a data integrity nightmare.
Can we please develop this feature for iomap based file systems first,
and if by then a use case for block devices arises I'll see what we can
do there. I've been planning to get the block device code to stop using
buffer_heads by default, but taking them into account if used by a
legacy buffer_head user anyway.
next prev parent reply other threads:[~2022-02-22 8:18 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 19:57 [PATCH v2 00/13] Support sync buffered writes for io-uring Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 01/13] fs: Add flags parameter to __block_write_begin_int Stefan Roesch
2022-02-18 19:59 ` Matthew Wilcox
2022-02-18 20:08 ` Stefan Roesch
2022-02-18 20:13 ` Matthew Wilcox
2022-02-18 20:14 ` Stefan Roesch
2022-02-18 20:22 ` Matthew Wilcox
2022-02-18 20:25 ` Stefan Roesch
2022-02-18 20:35 ` Matthew Wilcox
2022-02-18 20:39 ` Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 02/13] mm: Introduce do_generic_perform_write Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 03/13] mm: Add support for async buffered writes Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 04/13] fs: split off __alloc_page_buffers function Stefan Roesch
2022-02-18 20:42 ` Matthew Wilcox
2022-02-18 20:50 ` Stefan Roesch
2022-02-19 7:35 ` Christoph Hellwig
2022-02-20 4:23 ` Matthew Wilcox
2022-02-20 4:38 ` Jens Axboe
2022-02-20 4:51 ` Jens Axboe
2022-02-22 8:18 ` Christoph Hellwig [this message]
2022-02-22 23:19 ` Jens Axboe
2022-02-18 19:57 ` [PATCH v2 05/13] fs: split off __create_empty_buffers function Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 06/13] fs: Add gfp_t parameter to create_page_buffers() Stefan Roesch
2022-02-21 0:18 ` kernel test robot
2022-02-18 19:57 ` [PATCH v2 07/13] fs: add support for async buffered writes Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 08/13] io_uring: " Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 09/13] io_uring: Add tracepoint for short writes Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 10/13] sched: add new fields to task_struct Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 11/13] mm: support write throttling for async buffered writes Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 12/13] io_uring: " Stefan Roesch
2022-02-18 19:57 ` [PATCH v2 13/13] block: enable async buffered writes for block devices Stefan Roesch
2022-02-20 22:38 ` [PATCH v2 00/13] Support sync buffered writes for io-uring Dave Chinner
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=YhScWzgGVyeaufvU@infradead.org \
--to=hch@infradead.org \
--cc=io-uring@vger.kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=shr@fb.com \
--cc=willy@infradead.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.