From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([65.50.211.133]:60737 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753652AbdCBARc (ORCPT ); Wed, 1 Mar 2017 19:17:32 -0500 Date: Wed, 1 Mar 2017 15:56:24 -0800 From: Christoph Hellwig Subject: Re: [PATCH RFC] xfs: use iomap new flag for newly allocated delalloc blocks Message-ID: <20170301235624.GA29200@infradead.org> References: <1488379009-4972-1-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1488379009-4972-1-git-send-email-bfoster@redhat.com> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Brian Foster Cc: linux-xfs@vger.kernel.org, Xiong Zhou , Christoph Hellwig On Wed, Mar 01, 2017 at 09:36:49AM -0500, Brian Foster wrote: > This is a stab at fixing the regression discussed in this[1] thread > based on what Christoph mentioned regarding use of the IOMAP_F_NEW flag. > I decided to co-opt the XFS_BMAPI_ENTIRE flag for the delalloc res bit > since it seems logically equivalent, but we could define a new flag too. > I considered as such to preserve default behavior of > _reserve_delalloc(), but otoh there is only one other caller. Otherwise, > this passes all of my testing so far. Thoughts? I don't like reusing the flag that much, but I think instead of passing the flag we could trivially just remove the xfs_bmbt_get_all in xfs_bmapi_reserve_delalloc and let the caller handle it after xfs_bmapi_reserve_delalloc returned. That being said I see no good reason why the COW would care to see the merged extent, so unconditionally removing it should be fine as well. Or did I miss something?