From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 20 Jun 2017 09:34:56 +0200 From: Christoph Hellwig To: Al Viro Cc: Christoph Hellwig , Dan Williams , Andrew Morton , Jan Kara , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Chinner , "linux-kernel@vger.kernel.org" , Linux MM , Jeff Moyer , linux-fsdevel , Ross Zwisler Subject: Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Message-ID: <20170620073456.GA8453@lst.de> References: <149766212410.22552.15957843500156182524.stgit@dwillia2-desk3.amr.corp.intel.com> <149766212976.22552.11210067224152823950.stgit@dwillia2-desk3.amr.corp.intel.com> <20170617052212.GA8246@lst.de> <20170618075152.GA25871@lst.de> <20170619181956.GH10672@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk> Sender: owner-linux-mm@kvack.org List-ID: 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: email@kvack.org