From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [Cluster-devel] [PATCH 11/34] iomap: move IOMAP_F_BOUNDARY to gfs2 To: Christoph Hellwig Cc: "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, cluster-devel@redhat.com, linux-mm@kvack.org, =?UTF-8?Q?Andreas_Gr=c3=bcnbacher?= References: <20180523144357.18985-1-hch@lst.de> <20180523144357.18985-12-hch@lst.de> <20180530055033.GZ30110@magnolia> <20180530095911.GB31068@lst.de> From: Steven Whitehouse Message-ID: Date: Wed, 30 May 2018 11:02:08 +0100 MIME-Version: 1.0 In-Reply-To: <20180530095911.GB31068@lst.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: Hi, On 30/05/18 10:59, Christoph Hellwig wrote: > On Wed, May 30, 2018 at 10:30:32AM +0100, Steven Whitehouse wrote: >> I may have missed the context here, but I thought that the boundary wa= s a >> generic thing meaning "there will have to be a metadata read before mo= re >> blocks can be mapped" so I'm not sure why that would now be GFS2 speci= fic? > It was always a hack. But with iomap it doesn't make any sensee to sta= rt > with, all metadata I/O happens in iomap_begin, so there is no point in > marking an iomap with flags like this for the actual iomap interface. In that case,=C2=A0 maybe it would be simpler to drop it for GFS2. Unless= we=20 are getting a lot of benefit from it, then we should probably just=20 follow the generic pattern here. Eventually we'll move everything to=20 iomap, so that the bh mapping interface will be gone. That implies that=20 we might be able to drop it now, to avoid this complication during the=20 conversion. Andreas, do you see any issues with that? Steve.