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> <20180530101003.GA31419@lst.de> From: Steven Whitehouse Message-ID: <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> Date: Wed, 30 May 2018 11:12:43 +0100 MIME-Version: 1.0 In-Reply-To: <20180530101003.GA31419@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 11:10, Christoph Hellwig wrote: > On Wed, May 30, 2018 at 11:02:08AM +0100, Steven Whitehouse wrote: >> In that case,=C2=A0 maybe it would be simpler to drop it for GFS2. Unl= ess we >> are getting a lot of benefit from it, then we should probably just fol= low >> the generic pattern here. Eventually we'll move everything to iomap, s= o >> that the bh mapping interface will be gone. That implies that we might= be >> able to drop it now, to avoid this complication during the conversion.= >> >> Andreas, do you see any issues with that? > I suspect it actually is doing the wrong thing today. It certainly > does for SSDs, and it probably doesn't do a useful thing for modern > disks with intelligent caches either. Yes, agreed that it makes no sense for SSDs, Steve. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Wed, 30 May 2018 11:12:43 +0100 Subject: [Cluster-devel] [PATCH 11/34] iomap: move IOMAP_F_BOUNDARY to gfs2 In-Reply-To: <20180530101003.GA31419@lst.de> References: <20180523144357.18985-1-hch@lst.de> <20180523144357.18985-12-hch@lst.de> <20180530055033.GZ30110@magnolia> <20180530095911.GB31068@lst.de> <20180530101003.GA31419@lst.de> Message-ID: <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On 30/05/18 11:10, Christoph Hellwig wrote: > On Wed, May 30, 2018 at 11:02:08AM +0100, Steven Whitehouse wrote: >> In that case,? maybe it would be simpler to drop it for GFS2. Unless we >> are getting a lot of benefit from it, then we should probably just follow >> the generic pattern here. Eventually we'll move everything to iomap, so >> that the bh mapping interface will be gone. That implies that we might be >> able to drop it now, to avoid this complication during the conversion. >> >> Andreas, do you see any issues with that? > I suspect it actually is doing the wrong thing today. It certainly > does for SSDs, and it probably doesn't do a useful thing for modern > disks with intelligent caches either. Yes, agreed that it makes no sense for SSDs, Steve.