From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> References: <20180523144357.18985-1-hch@lst.de> <20180523144357.18985-12-hch@lst.de> <20180530055033.GZ30110@magnolia> <20180530095911.GB31068@lst.de> <20180530101003.GA31419@lst.de> <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> From: Andreas Gruenbacher Date: Wed, 30 May 2018 13:03:00 +0200 Message-ID: Subject: Re: [Cluster-devel] [PATCH 11/34] iomap: move IOMAP_F_BOUNDARY to gfs2 To: Steven Whitehouse Cc: Christoph Hellwig , "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-fsdevel , cluster-devel , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: On 30 May 2018 at 12:12, Steven Whitehouse wrote: > 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? We're not handling reads through iomap yet, so I'd be happier with keeping that flag in one form or the other until we get there. This will go away eventually anyway. >> 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, Thanks, Andreas From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Gruenbacher Date: Wed, 30 May 2018 13:03:00 +0200 Subject: [Cluster-devel] [PATCH 11/34] iomap: move IOMAP_F_BOUNDARY to gfs2 In-Reply-To: <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> References: <20180523144357.18985-1-hch@lst.de> <20180523144357.18985-12-hch@lst.de> <20180530055033.GZ30110@magnolia> <20180530095911.GB31068@lst.de> <20180530101003.GA31419@lst.de> <8a9e048b-f60c-90bc-6884-e2fa6eca2c28@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 30 May 2018 at 12:12, Steven Whitehouse wrote: > 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? We're not handling reads through iomap yet, so I'd be happier with keeping that flag in one form or the other until we get there. This will go away eventually anyway. >> 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, Thanks, Andreas