From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Fri, 6 Apr 2018 11:08:35 -0400 (EDT) Subject: [Cluster-devel] [PATCH v3 6/8] gfs2: Implement iomap direct I/O support In-Reply-To: <20180323191728.23819-7-agruenba@redhat.com> References: <20180323191728.23819-1-agruenba@redhat.com> <20180323191728.23819-7-agruenba@redhat.com> Message-ID: <91110851.16618674.1523027315785.JavaMail.zimbra@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, ----- Original Message ----- > With that, the direct_IO address space operation can be all but > eliminated: only a dummy remains which indicates that the filesystem > supports direct I/O. > > Signed-off-by: Andreas Gruenbacher > --- > fs/gfs2/aops.c | 92 +------------------------------ > fs/gfs2/bmap.c | 14 ++++- > fs/gfs2/file.c | 171 > +++++++++++++++++++++++++++++++++++++++++++++++++++++---- > 3 files changed, 174 insertions(+), 103 deletions(-) (snip) > + pos = iocb->ki_pos; > + endbyte = pos + buffered - 1; > + ret = filemap_write_and_wait_range(mapping, pos, endbyte); > + if (!ret) { > + iocb->ki_pos += buffered; > + written += buffered; > + invalidate_mapping_pages(mapping, > + pos >> PAGE_SHIFT, > + endbyte >> PAGE_SHIFT); > + } else { > + /* > + * We don't know how much we wrote, so just return > + * the number of bytes which were direct-written > + */ Can't we get in trouble here because we don't update iocb->io_pos? Regards, Bob Peterson From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:55002 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751726AbeDFPIg (ORCPT ); Fri, 6 Apr 2018 11:08:36 -0400 Date: Fri, 6 Apr 2018 11:08:35 -0400 (EDT) From: Bob Peterson To: Andreas Gruenbacher Cc: cluster-devel@redhat.com, Christoph Hellwig , linux-fsdevel@vger.kernel.org Message-ID: <91110851.16618674.1523027315785.JavaMail.zimbra@redhat.com> In-Reply-To: <20180323191728.23819-7-agruenba@redhat.com> References: <20180323191728.23819-1-agruenba@redhat.com> <20180323191728.23819-7-agruenba@redhat.com> Subject: Re: [Cluster-devel] [PATCH v3 6/8] gfs2: Implement iomap direct I/O support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, ----- Original Message ----- > With that, the direct_IO address space operation can be all but > eliminated: only a dummy remains which indicates that the filesystem > supports direct I/O. > > Signed-off-by: Andreas Gruenbacher > --- > fs/gfs2/aops.c | 92 +------------------------------ > fs/gfs2/bmap.c | 14 ++++- > fs/gfs2/file.c | 171 > +++++++++++++++++++++++++++++++++++++++++++++++++++++---- > 3 files changed, 174 insertions(+), 103 deletions(-) (snip) > + pos = iocb->ki_pos; > + endbyte = pos + buffered - 1; > + ret = filemap_write_and_wait_range(mapping, pos, endbyte); > + if (!ret) { > + iocb->ki_pos += buffered; > + written += buffered; > + invalidate_mapping_pages(mapping, > + pos >> PAGE_SHIFT, > + endbyte >> PAGE_SHIFT); > + } else { > + /* > + * We don't know how much we wrote, so just return > + * the number of bytes which were direct-written > + */ Can't we get in trouble here because we don't update iocb->io_pos? Regards, Bob Peterson