From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC PATCH 1/2] mm: introduce bmap_walk() Date: Tue, 20 Jun 2017 09:34:56 +0200 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 Return-path: Content-Disposition: inline In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk> Sender: owner-linux-mm@kvack.org 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 List-Id: linux-api@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 312F32095D211 for ; Tue, 20 Jun 2017 00:33:36 -0700 (PDT) Date: Tue, 20 Jun 2017 09:34:56 +0200 From: Christoph Hellwig 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-Disposition: inline In-Reply-To: <20170619181956.GH10672@ZenIV.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Al Viro Cc: Jan Kara , Andrew Morton , "linux-nvdimm@lists.01.org" , linux-api@vger.kernel.org, Dave Chinner , "linux-kernel@vger.kernel.org" , Linux MM , linux-fsdevel , Christoph Hellwig 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. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751130AbdFTHfA (ORCPT ); Tue, 20 Jun 2017 03:35:00 -0400 Received: from verein.lst.de ([213.95.11.211]:33481 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbdFTHe6 (ORCPT ); Tue, 20 Jun 2017 03:34:58 -0400 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> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.