From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Jeff Moyer <jmoyer@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [RFC PATCH 1/2] mm: introduce bmap_walk()
Date: Tue, 20 Jun 2017 09:34:56 +0200 [thread overview]
Message-ID: <20170620073456.GA8453@lst.de> (raw)
In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk>
On Mon, Jun 19, 2017 at 07:19:57PM +0100, Al Viro wrote:
> Speaking of iomap, what's supposed to happen when doing a write into what
> used to be a hole? Suppose we have a file with a megabyte hole in it
> and there's some process mmapping that range. Another process does
> write over the entire range. We call ->iomap_begin() and allocate
> disk blocks. Then we start copying data into those. In the meanwhile,
> the first process attempts to fetch from address in the middle of that
> hole. What should happen?
Right now the buffered iomap code expects delayed allocations.
So ->iomap_begin will only reserve block in memory, and not even
mark the blocks as allocated in the page / buffer_head. The fact
that the block is allocated is only propagated into the page buffer_head
on a page by page basis in the actor.
> Should the blocks we'd allocated in ->iomap_begin() be immediately linked
> into the whatever indirect locks/btree/whatnot we are using? That would
> require zeroing all of them first - otherwise that readpage will read
> uninitialized block. Another variant would be to delay linking them
> in until ->iomap_end(), but... Suppose we get the page evicted by
> memory pressure after the writer is finished with it. If ->readpage()
> comes before ->iomap_end(), we'll need to somehow figure out that it's
> not a hole anymore, or we'll end up with an uptodate page full of zeroes
> observed by reads after successful write().
Delayed blocks are ignored by the read code, so it will read 'through'
them.
> The comment you've got in linux/iomap.h would seem to suggest the second
> interpretation, but neither it nor anything in Documentation discusses the
> relations with readpage/writepage...
I'll see if I can come up with some better documentation.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 1/2] mm: introduce bmap_walk()
Date: Tue, 20 Jun 2017 09:34:56 +0200 [thread overview]
Message-ID: <20170620073456.GA8453@lst.de> (raw)
In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk>
On Mon, Jun 19, 2017 at 07:19:57PM +0100, Al Viro wrote:
> Speaking of iomap, what's supposed to happen when doing a write into what
> used to be a hole? Suppose we have a file with a megabyte hole in it
> and there's some process mmapping that range. Another process does
> write over the entire range. We call ->iomap_begin() and allocate
> disk blocks. Then we start copying data into those. In the meanwhile,
> the first process attempts to fetch from address in the middle of that
> hole. What should happen?
Right now the buffered iomap code expects delayed allocations.
So ->iomap_begin will only reserve block in memory, and not even
mark the blocks as allocated in the page / buffer_head. The fact
that the block is allocated is only propagated into the page buffer_head
on a page by page basis in the actor.
> Should the blocks we'd allocated in ->iomap_begin() be immediately linked
> into the whatever indirect locks/btree/whatnot we are using? That would
> require zeroing all of them first - otherwise that readpage will read
> uninitialized block. Another variant would be to delay linking them
> in until ->iomap_end(), but... Suppose we get the page evicted by
> memory pressure after the writer is finished with it. If ->readpage()
> comes before ->iomap_end(), we'll need to somehow figure out that it's
> not a hole anymore, or we'll end up with an uptodate page full of zeroes
> observed by reads after successful write().
Delayed blocks are ignored by the read code, so it will read 'through'
them.
> The comment you've got in linux/iomap.h would seem to suggest the second
> interpretation, but neither it nor anything in Documentation discusses the
> relations with readpage/writepage...
I'll see if I can come up with some better documentation.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
linux-api@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>, Jeff Moyer <jmoyer@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Ross Zwisler <ross.zwisler@linux.intel.com>
Subject: Re: [RFC PATCH 1/2] mm: introduce bmap_walk()
Date: Tue, 20 Jun 2017 09:34:56 +0200 [thread overview]
Message-ID: <20170620073456.GA8453@lst.de> (raw)
In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk>
On Mon, Jun 19, 2017 at 07:19:57PM +0100, Al Viro wrote:
> Speaking of iomap, what's supposed to happen when doing a write into what
> used to be a hole? Suppose we have a file with a megabyte hole in it
> and there's some process mmapping that range. Another process does
> write over the entire range. We call ->iomap_begin() and allocate
> disk blocks. Then we start copying data into those. In the meanwhile,
> the first process attempts to fetch from address in the middle of that
> hole. What should happen?
Right now the buffered iomap code expects delayed allocations.
So ->iomap_begin will only reserve block in memory, and not even
mark the blocks as allocated in the page / buffer_head. The fact
that the block is allocated is only propagated into the page buffer_head
on a page by page basis in the actor.
> Should the blocks we'd allocated in ->iomap_begin() be immediately linked
> into the whatever indirect locks/btree/whatnot we are using? That would
> require zeroing all of them first - otherwise that readpage will read
> uninitialized block. Another variant would be to delay linking them
> in until ->iomap_end(), but... Suppose we get the page evicted by
> memory pressure after the writer is finished with it. If ->readpage()
> comes before ->iomap_end(), we'll need to somehow figure out that it's
> not a hole anymore, or we'll end up with an uptodate page full of zeroes
> observed by reads after successful write().
Delayed blocks are ignored by the read code, so it will read 'through'
them.
> The comment you've got in linux/iomap.h would seem to suggest the second
> interpretation, but neither it nor anything in Documentation discusses the
> relations with readpage/writepage...
I'll see if I can come up with some better documentation.
next prev parent reply other threads:[~2017-06-20 7:34 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-17 1:15 [RFC PATCH 0/2] daxfile: enable byte-addressable updates to pmem Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 1:15 ` Dan Williams
[not found] ` <149766212410.22552.15957843500156182524.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-06-17 1:15 ` [RFC PATCH 1/2] mm: introduce bmap_walk() Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 5:22 ` Christoph Hellwig
2017-06-17 5:22 ` Christoph Hellwig
[not found] ` <20170617052212.GA8246-jcswGhMUV9g@public.gmane.org>
2017-06-17 12:29 ` Dan Williams
2017-06-17 12:29 ` Dan Williams
2017-06-17 12:29 ` Dan Williams
2017-06-17 12:29 ` Dan Williams
2017-06-18 7:51 ` Christoph Hellwig
2017-06-18 7:51 ` Christoph Hellwig
2017-06-18 7:51 ` Christoph Hellwig
2017-06-19 16:18 ` Darrick J. Wong
2017-06-19 16:18 ` Darrick J. Wong
[not found] ` <20170618075152.GA25871-jcswGhMUV9g@public.gmane.org>
2017-06-19 18:19 ` Al Viro
2017-06-19 18:19 ` Al Viro
2017-06-19 18:19 ` Al Viro
2017-06-19 18:19 ` Al Viro
2017-06-20 7:34 ` Christoph Hellwig [this message]
2017-06-20 7:34 ` Christoph Hellwig
2017-06-20 7:34 ` Christoph Hellwig
2017-06-17 1:15 ` [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem Dan Williams
2017-06-17 1:15 ` Dan Williams
2017-06-17 1:15 ` Dan Williams
[not found] ` <149766213493.22552.4057048843646200083.stgit-p8uTFz9XbKj2zm6wflaqv1nYeNYlB/vhral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-06-17 16:25 ` Andy Lutomirski
2017-06-17 16:25 ` Andy Lutomirski
2017-06-17 16:25 ` Andy Lutomirski
2017-06-17 16:25 ` Andy Lutomirski
2017-06-17 21:52 ` Dan Williams
2017-06-17 21:52 ` Dan Williams
2017-06-17 21:52 ` Dan Williams
[not found] ` <CAPcyv4j4UEegViDJcLZjVv5AFGC18-DcvHFnhZatB0hH3BY85g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-17 23:50 ` Andy Lutomirski
2017-06-17 23:50 ` Andy Lutomirski
2017-06-17 23:50 ` Andy Lutomirski
2017-06-17 23:50 ` Andy Lutomirski
2017-06-18 3:15 ` Dan Williams
2017-06-18 3:15 ` Dan Williams
2017-06-18 3:15 ` Dan Williams
2017-06-18 5:05 ` Andy Lutomirski
2017-06-18 5:05 ` Andy Lutomirski
2017-06-18 5:05 ` Andy Lutomirski
[not found] ` <CALCETrVY38h2ajpod2U_2pdHSp8zO4mG2p19h=OnnHmhGTairw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-19 13:21 ` Dave Chinner
2017-06-19 13:21 ` Dave Chinner
2017-06-19 13:21 ` Dave Chinner
2017-06-19 13:21 ` Dave Chinner
2017-06-19 15:22 ` Andy Lutomirski
2017-06-19 15:22 ` Andy Lutomirski
2017-06-19 15:22 ` Andy Lutomirski
[not found] ` <CALCETrUe0igzK0RZTSSondkCY3ApYQti89tOh00f0j_APrf_dQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-20 0:46 ` Dave Chinner
2017-06-20 0:46 ` Dave Chinner
2017-06-20 0:46 ` Dave Chinner
2017-06-20 0:46 ` Dave Chinner
2017-06-20 5:53 ` Andy Lutomirski
2017-06-20 5:53 ` Andy Lutomirski
2017-06-20 5:53 ` Andy Lutomirski
2017-06-20 5:53 ` Andy Lutomirski
2017-06-20 8:49 ` Christoph Hellwig
2017-06-20 8:49 ` Christoph Hellwig
2017-06-20 8:49 ` Christoph Hellwig
[not found] ` <20170620084924.GA9752-jcswGhMUV9g@public.gmane.org>
2017-06-20 16:17 ` Dan Williams
2017-06-20 16:17 ` Dan Williams
2017-06-20 16:17 ` Dan Williams
2017-06-20 16:17 ` Dan Williams
[not found] ` <CAPcyv4jkH6iwDoG4NnCaTNXozwYgVXiJDe2iFSONcE63KvGQoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-20 16:26 ` Andy Lutomirski
2017-06-20 16:26 ` Andy Lutomirski
2017-06-20 16:26 ` Andy Lutomirski
2017-06-20 16:26 ` Andy Lutomirski
2017-06-20 23:53 ` Dave Chinner
2017-06-20 23:53 ` Dave Chinner
2017-06-20 23:53 ` Dave Chinner
2017-06-21 1:24 ` Darrick J. Wong
2017-06-21 1:24 ` Darrick J. Wong
2017-06-21 2:19 ` Dave Chinner
2017-06-21 2:19 ` Dave Chinner
2017-06-21 2:19 ` Dave Chinner
[not found] ` <CALCETrVuoPDRuuhc9X8eVCYiFUzWLSTRkcjbD6jas_2J2GixNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-20 10:11 ` Dave Chinner
2017-06-20 10:11 ` Dave Chinner
2017-06-20 10:11 ` Dave Chinner
2017-06-20 10:11 ` Dave Chinner
2017-06-20 16:14 ` Andy Lutomirski
2017-06-20 16:14 ` Andy Lutomirski
2017-06-20 16:14 ` Andy Lutomirski
2017-06-20 16:14 ` Andy Lutomirski
2017-06-21 1:40 ` Dave Chinner
2017-06-21 1:40 ` Dave Chinner
2017-06-21 1:40 ` Dave Chinner
2017-06-21 5:18 ` Andy Lutomirski
2017-06-21 5:18 ` Andy Lutomirski
2017-06-21 5:18 ` Andy Lutomirski
2017-06-21 5:18 ` Andy Lutomirski
[not found] ` <CALCETrVYmbyNS-btvsN_M-QyWPZA_Y_4JXOM893g7nhZA+WviQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-22 0:02 ` Dave Chinner
2017-06-22 0:02 ` Dave Chinner
2017-06-22 0:02 ` Dave Chinner
2017-06-22 0:02 ` Dave Chinner
2017-06-22 4:07 ` Andy Lutomirski
2017-06-22 4:07 ` Andy Lutomirski
2017-06-22 4:07 ` Andy Lutomirski
2017-06-22 4:07 ` Andy Lutomirski
2017-06-23 0:52 ` Dave Chinner
2017-06-23 0:52 ` Dave Chinner
2017-06-23 0:52 ` Dave Chinner
2017-06-23 3:07 ` Andy Lutomirski
2017-06-23 3:07 ` Andy Lutomirski
2017-06-23 3:07 ` Andy Lutomirski
2017-06-18 8:18 ` Christoph Hellwig
2017-06-18 8:18 ` Christoph Hellwig
[not found] ` <20170618081850.GA26332-jcswGhMUV9g@public.gmane.org>
2017-06-19 1:51 ` Dan Williams
2017-06-19 1:51 ` Dan Williams
2017-06-19 1:51 ` Dan Williams
2017-06-19 1:51 ` Dan Williams
2017-06-20 5:22 ` Darrick J. Wong
2017-06-20 5:22 ` Darrick J. Wong
2017-06-20 15:42 ` Ross Zwisler
2017-06-20 15:42 ` Ross Zwisler
2017-06-22 7:09 ` Darrick J. Wong
2017-06-22 7:09 ` Darrick J. Wong
[not found] ` <20170620052214.GA3787-PTl6brltDGh4DFYR7WNSRA@public.gmane.org>
2017-06-21 23:37 ` Dave Chinner
2017-06-21 23:37 ` Dave Chinner
2017-06-21 23:37 ` Dave Chinner
2017-06-21 23:37 ` Dave Chinner
2017-06-22 7:23 ` Darrick J. Wong
2017-06-22 7:23 ` Darrick J. Wong
2017-06-22 7:23 ` Darrick J. Wong
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=20170620073456.GA8453@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=ross.zwisler@linux.intel.com \
--cc=viro@ZenIV.linux.org.uk \
/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.