From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Cc: Ritesh Harjani <riteshh@linux.ibm.com>,
jack@suse.cz, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC 0/5] Ext4: Add support for blocksize < pagesize for dioread_nolock
Date: Mon, 4 Nov 2019 11:08:23 -0500 [thread overview]
Message-ID: <20191104160823.GI28764@mit.edu> (raw)
In-Reply-To: <20191104104913.GC27115@bobrowski>
On Mon, Nov 04, 2019 at 09:49:14PM +1100, Matthew Bobrowski wrote:
> > It sure may be giving a merge conflict (due to io_end structure).
> > But this dioread_nolock series was not dependent over iomap series.
>
> Uh ha. Well, there's been a chunk of code injected into
> ext4_end_io_dio() here and by me removing it, I'm not entirely sure
> what the downstream effects will be for this specific change...
Yeah, that was probably my failure to do the merge correctly; I'm
hoping that Ritesh will be able to fix that up. If not we can throw
an "experimental" config to enable dioread_nolock on subpage
blocksizes, just to warn people that under some extreme workloads,
they might end up corrupting their allocation bitmap, which then might
lead to data loss. I suspect it would actually work fine for most
users; but out of paranoia, if we can't figure out the generic/270
failure before the merge window, we can just make dioread_nolock_1k
experimental for now.
- Ted
next prev parent reply other threads:[~2019-11-04 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 7:37 [RFC 0/5] Ext4: Add support for blocksize < pagesize for dioread_nolock Ritesh Harjani
2019-10-16 7:37 ` [RFC 1/5] ext4: keep uniform naming convention for io & io_end variables Ritesh Harjani
2019-10-25 13:07 ` Jan Kara
2019-10-16 7:37 ` [RFC 2/5] ext4: Add API to bring in support for unwritten io_end_vec conversion Ritesh Harjani
2019-10-16 7:37 ` [RFC 3/5] ext4: Refactor mpage_map_and_submit_buffers function Ritesh Harjani
2019-10-16 7:37 ` [RFC 4/5] ext4: Add support for blocksize < pagesize in dioread_nolock Ritesh Harjani
2019-10-16 7:37 ` [RFC 5/5] ext4: Enable blocksize < pagesize for dioread_nolock Ritesh Harjani
2019-10-23 23:26 ` [RFC 0/5] Ext4: Add support for " Theodore Y. Ts'o
2019-10-24 1:12 ` Ritesh Harjani
2019-10-29 7:19 ` Ritesh Harjani
2019-11-03 19:16 ` Theodore Y. Ts'o
2019-11-04 10:16 ` Matthew Bobrowski
2019-11-04 10:37 ` Ritesh Harjani
2019-11-04 10:49 ` Matthew Bobrowski
2019-11-04 16:08 ` Theodore Y. Ts'o [this message]
2019-11-04 10:43 ` Ritesh Harjani
2019-11-04 11:59 ` Ritesh Harjani
2019-11-06 17:23 ` Jan Kara
2019-11-07 11:15 ` Ritesh Harjani
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=20191104160823.GI28764@mit.edu \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mbobrowski@mbobrowski.org \
--cc=riteshh@linux.ibm.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.