From: Kent Overstreet <kent.overstreet@linux.dev>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 06/32] sched: Add task_struct->faults_disabled_mapping
Date: Fri, 26 May 2023 04:38:41 -0400 [thread overview]
Message-ID: <ZHBwEYupK2gxLOjn@moria.home.lan> (raw)
In-Reply-To: <ZHBpg4ndZ2CLP7mi@infradead.org>
On Fri, May 26, 2023 at 01:10:43AM -0700, Christoph Hellwig wrote:
> On Thu, May 25, 2023 at 07:20:46PM -0400, Kent Overstreet wrote:
> > > > I'm absolutely not in favour to add workarounds for thes kind of locking
> > > > problems to the core kernel. I already feel bad for allowing the
> > > > small workaround in iomap for btrfs, as just fixing the locking back
> > > > then would have avoid massive ratholing.
> > >
> > > Please let me know when those btrfs changes are in a presentable shape ...
> >
> > I would also be curious to know what btrfs needs and what the approach
> > is there.
>
> btrfs has the extent locked, where "extent locked" is a somewhat magic
> range lock that actually includes different lock bits. It does so
> because it clears the page writeback bit when the data made it to the
> media, but before the metadata required to find it is commited, and
> the extent lock prevents it from trying to do a readpage on something
> that has actually very recently been written back but not fully
> commited. Once btrfs is changed to only clear the page writeback bit
> once the write is fully commited like in other file systems this extra
> level of locking can go away, and there are no more locks in the
> readpage path that are also taken by the direct I/O code. With that
> a lot of code in btrfs working around this can go away, including the
> no fault direct I/O code.
wow, yeah, that is not how that is supposed to work...
next prev parent reply other threads:[~2023-05-26 8:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230509165657.1735798-1-kent.overstreet@linux.dev>
[not found] ` <20230509165657.1735798-7-kent.overstreet@linux.dev>
[not found] ` <20230510010737.heniyuxazlprrbd6@quack3>
[not found] ` <ZFs3RYgdCeKjxYCw@moria.home.lan>
2023-05-23 13:34 ` [Cluster-devel] [PATCH 06/32] sched: Add task_struct->faults_disabled_mapping Jan Kara
2023-05-23 16:21 ` Christoph Hellwig
2023-05-23 16:35 ` Kent Overstreet
2023-05-24 6:43 ` Christoph Hellwig
2023-05-24 8:09 ` Kent Overstreet
2023-05-25 8:58 ` Christoph Hellwig
2023-05-25 20:50 ` Kent Overstreet
2023-05-26 8:06 ` Christoph Hellwig
2023-05-26 8:34 ` Kent Overstreet
2023-05-25 21:40 ` Kent Overstreet
2023-05-25 22:25 ` Andreas Grünbacher
2023-05-25 23:20 ` Kent Overstreet
2023-05-26 0:05 ` Andreas Grünbacher
2023-05-26 0:39 ` Kent Overstreet
2023-05-26 8:10 ` Christoph Hellwig
2023-05-26 8:38 ` Kent Overstreet [this message]
2023-05-23 16:49 ` Kent Overstreet
2023-05-25 8:47 ` Jan Kara
2023-05-25 21:36 ` Kent Overstreet
2023-05-25 22:45 ` Andreas Grünbacher
2023-05-25 22:04 ` Andreas Grünbacher
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=ZHBwEYupK2gxLOjn@moria.home.lan \
--to=kent.overstreet@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).