linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>

  reply	other threads:[~2017-06-20  7:34 UTC|newest]

Thread overview: 39+ 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 ` [RFC PATCH 1/2] mm: introduce bmap_walk() Dan Williams
2017-06-17  5:22   ` Christoph Hellwig
2017-06-17 12:29     ` Dan Williams
2017-06-18  7:51       ` Christoph Hellwig
2017-06-19 16:18         ` Darrick J. Wong
2017-06-19 18:19         ` Al Viro
2017-06-20  7:34           ` Christoph Hellwig [this message]
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 16:25   ` Andy Lutomirski
2017-06-17 21:52     ` Dan Williams
2017-06-17 23:50       ` Andy Lutomirski
2017-06-18  3:15         ` Dan Williams
2017-06-18  5:05           ` Andy Lutomirski
2017-06-19 13:21             ` Dave Chinner
2017-06-19 15:22               ` Andy Lutomirski
2017-06-20  0:46                 ` Dave Chinner
2017-06-20  5:53                   ` Andy Lutomirski
2017-06-20  8:49                     ` Christoph Hellwig
2017-06-20 16:17                       ` Dan Williams
2017-06-20 16:26                         ` Andy Lutomirski
2017-06-20 23:53                         ` Dave Chinner
2017-06-21  1:24                           ` Darrick J. Wong
2017-06-21  2:19                             ` Dave Chinner
2017-06-20 10:11                     ` Dave Chinner
2017-06-20 16:14                       ` Andy Lutomirski
2017-06-21  1:40                         ` Dave Chinner
2017-06-21  5:18                           ` Andy Lutomirski
2017-06-22  0:02                             ` Dave Chinner
2017-06-22  4:07                               ` Andy Lutomirski
2017-06-23  0:52                                 ` Dave Chinner
2017-06-23  3:07                                   ` Andy Lutomirski
2017-06-18  8:18           ` Christoph Hellwig
2017-06-19  1:51             ` Dan Williams
2017-06-20  5:22   ` Darrick J. Wong
2017-06-20 15:42     ` Ross Zwisler
2017-06-22  7:09       ` Darrick J. Wong
2017-06-21 23:37     ` Dave Chinner
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 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 NNTP newsgroup(s).