From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68F27C433DB for ; Wed, 3 Mar 2021 09:43:33 +0000 (UTC) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DCD4764EEB for ; Wed, 3 Mar 2021 09:43:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCD4764EEB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=ocfs2-devel-bounces@oss.oracle.com Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1239Psec167625; Wed, 3 Mar 2021 09:43:32 GMT Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 371hhc433f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Mar 2021 09:43:32 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1239Op4k023089; Wed, 3 Mar 2021 09:43:31 GMT Received: from oss.oracle.com (oss-old-reserved.oracle.com [137.254.22.2]) by userp3020.oracle.com with ESMTP id 36yyut7fjc-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 03 Mar 2021 09:43:31 +0000 Received: from localhost ([127.0.0.1] helo=lb-oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1lHO2U-0007px-Fr; Wed, 03 Mar 2021 01:43:30 -0800 Received: from userp3030.oracle.com ([156.151.31.80]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from ) id 1lHO2T-0007pj-Q9 for ocfs2-devel@oss.oracle.com; Wed, 03 Mar 2021 01:43:29 -0800 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1239PIIR100029 for ; Wed, 3 Mar 2021 09:43:29 GMT Received: from userp2040.oracle.com (userp2040.oracle.com [156.151.31.90]) by userp3030.oracle.com with ESMTP id 37000y70qe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 03 Mar 2021 09:43:29 +0000 Received: from pps.filterd (userp2040.oracle.com [127.0.0.1]) by userp2040.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 1239hSI4002127 for ; Wed, 3 Mar 2021 09:43:29 GMT Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by userp2040.oracle.com with ESMTP id 36ycpvk5bj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 03 Mar 2021 09:43:28 +0000 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 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-Disposition: inline In-Reply-To: <20210226002030.653855-10-ruansy.fnst@fujitsu.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-PDR: PASS X-Source-IP: 213.95.11.211 X-ServerName: verein.lst.de X-Proofpoint-SPF-Result: None X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9911 signatures=668683 X-Proofpoint-Spam-Details: rule=tap_notspam policy=tap score=0 spamscore=0 priorityscore=0 lowpriorityscore=0 malwarescore=0 mlxscore=0 impostorscore=0 phishscore=0 bulkscore=0 clxscore=176 mlxlogscore=443 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103030073 X-Spam: Clean Cc: jack@suse.cz, darrick.wong@oracle.com, linux-nvdimm@lists.01.org, david@fromorbit.com, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, dan.j.williams@intel.com, linux-btrfs@vger.kernel.org Subject: Re: [Ocfs2-devel] [PATCH v2 09/10] fs/xfs: Handle CoW for fsdax write() path X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9911 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103030072 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9911 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1034 malwarescore=0 mlxlogscore=999 spamscore=0 phishscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 suspectscore=0 bulkscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103030072 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? _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel