Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1525781pxb; Thu, 4 Mar 2021 13:45:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJyHIeozIXi5dcRC+yz9kGDZLc231Zyes4KMgVQGSw2fZafHicQaQLsZKRFOXqWl75S4EWQ4 X-Received: by 2002:aa7:c346:: with SMTP id j6mr6597985edr.386.1614894324534; Thu, 04 Mar 2021 13:45:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614894324; cv=none; d=google.com; s=arc-20160816; b=WAUVI+3a/J6MicE9APiDCpEJjzFMw9H+LeTNPyeENw152xR7/YikxHfxL/6nyybd/j SGB/NAXVqkH7eDVwtGegO/PavbByf6pWZQx/JLLkZwaYUaJhlH8uBWGX8UNKgqTHrAJl ljXouGJiyAt0aXz2OXpy0GIKmUUPMj6FpuUNe1IEXg1KqeV8h4UrlFTFmoxMLVbo8TGa C9xsjFtmczv86aa2yNXqP9W7jTTdIkbk3rqir8XRCYSep17q+nSoPTssCEiRFHCjy2WX R+FTbL7iElrJXBulU0S7Ep1vrdL65FWqjha323fwJczL7WRv6PN3fQ9E757wqHKVQk3F COZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=GYHvCaENWNO6h2FmeUFsmd/6f6NTDEjOMrLGza44ZjE=; b=bXN3GBMuTQb/3POIl+5WfRVzyLq6dZ5+ApdWEOUWcyxvzNLv63oPkhYRIlkpF0vy0A 7XR+vHP/dHy7T3Awe6NSrsc8nRNCANv6wZ7h8EMmrxinAx4rH4FK4y12V7McHYMjv2GV wAKVum2bQeXYQqM8JwWq5GyLKWY8ZS9o1MkFN0e4ge1UoPi6i2ePkEhVW6rAXeiKXXOn 17jn5ZeO5j9UNMX6jU2t7Qdoe9kF5p7VwnlG9SRd2y6O/Gipf9Rz4bmEVWLiEzgl2+9j BEw4Bbb9wZKxc1pebByCvhoe3Q59kCLy5hx2iAdjD79tFQxRXBieQ5pC5jWgN04+1cyd ywFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z9si237192ejr.490.2021.03.04.13.45.01; Thu, 04 Mar 2021 13:45:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359412AbhCCOTL (ORCPT + 99 others); Wed, 3 Mar 2021 09:19:11 -0500 Received: from verein.lst.de ([213.95.11.211]:36062 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1842936AbhCCKWp (ORCPT ); Wed, 3 Mar 2021 05:22:45 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id EAEBC68D01; Wed, 3 Mar 2021 10:43:09 +0100 (CET) Date: Wed, 3 Mar 2021 10:43:09 +0100 From: Christoph Hellwig To: Shiyang Ruan Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com, dan.j.williams@intel.com, willy@infradead.org, jack@suse.cz, viro@zeniv.linux.org.uk, linux-btrfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, david@fromorbit.com, hch@lst.de, rgoldwyn@suse.de Subject: Re: [PATCH v2 09/10] fs/xfs: Handle CoW for fsdax write() path Message-ID: <20210303094309.GB15389@lst.de> References: <20210226002030.653855-1-ruansy.fnst@fujitsu.com> <20210226002030.653855-10-ruansy.fnst@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210226002030.653855-10-ruansy.fnst@fujitsu.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 26, 2021 at 08:20:29AM +0800, Shiyang Ruan wrote: > error = iomap_zero_range(VFS_I(ip), offset, len, NULL, > - &xfs_buffered_write_iomap_ops); > + IS_DAX(VFS_I(ip)) ? > + &xfs_dax_write_iomap_ops : &xfs_buffered_write_iomap_ops); Please add a xfs_zero_range helper that picks the right iomap_ops instead of open coding this in a few places. > +static int > +xfs_dax_write_iomap_end( > + struct inode *inode, > + loff_t pos, > + loff_t length, > + ssize_t written, > + unsigned int flags, > + struct iomap *iomap) > +{ > + int error = 0; > + xfs_inode_t *ip = XFS_I(inode); > + > + if (pos + written > i_size_read(inode)) { > + i_size_write(inode, pos + written); > + error = xfs_setfilesize(ip, pos, written); > + } > + if (xfs_is_cow_inode(ip)) > + error = xfs_reflink_end_cow(ip, pos, written); > + > + return error; What is the advantage of the ioemap_end handler here? It adds another indirect funtion call to the fast path, so if we can avoid it, I'd rather do that. Also, shouldn't we cancel the COW rather than finishing it when setting the file size fails?