From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id B7F7B6B02AA for ; Wed, 30 May 2018 07:03:02 -0400 (EDT) Received: by mail-io0-f197.google.com with SMTP id i1-v6so15182713ioh.15 for ; Wed, 30 May 2018 04:03:02 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 189-v6sor3583755itl.72.2018.05.30.04.03.01 for (Google Transport Security); Wed, 30 May 2018 04:03:01 -0700 (PDT) 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 Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Steven Whitehouse Cc: Christoph Hellwig , "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-fsdevel , cluster-devel , linux-mm@kvack.org 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