Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp339189pxm; Wed, 2 Mar 2022 16:47:15 -0800 (PST) X-Google-Smtp-Source: ABdhPJykt7285fd3QSyoZgVoSfWdee17C+XmsdmW6pDxGdaC5wrQH5IrmO7I7kFXx49bEuVeldE2 X-Received: by 2002:a05:6a00:218d:b0:4f6:4127:df4f with SMTP id h13-20020a056a00218d00b004f64127df4fmr6996377pfi.73.1646268434946; Wed, 02 Mar 2022 16:47:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646268434; cv=none; d=google.com; s=arc-20160816; b=EXluwF9QJ0N3aQa1ZFcmTnlXL4H5Og1Xh1puS0d46uCaSbQaxj5wMxpizIO7Yg24Su g56kHzov17fZ0v6Kj5xbHRmMcaVI7LJQ2Ep8Xt7H6ADMO2xs1G3uwNNVE1DoDiQ488B1 77EinJJdrORxV8pyfZkA2OiWkktkxk2AqUVK7Dp8pcFeHX+IneJM6u+9drpyZN93aUhi 73ZMUgaUxTVKHqpkZZK804MZ5ZYR0RYa+3XOhm6YLwg7PrY8B4c5SrwH0ZRNOL/wPfE9 Gtmy4K73VT5ftuhrKCIfQXu5lZdXxF56AnuyjUco8oU9MKCEO544D9QYAtVpcFORCfnY WDVA== 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 :dkim-signature:dkim-filter; bh=+2OkF/NbJLCsAX1YGMh/jwrJmXkW2FAPJw5PAYnoPYc=; b=yaFTfuo0Y2+csH3yy6lZ5Bi16ytvIeug59CM6CV6gG1PznmipT4qal81oTxURw8NjR 8NjvU/IqNQgV+PoS8wbfz2chFR7t7s4m58KTLw0JDjnH+tOOBpHN4HEKkQ26PBXyeYht t8mh3eXo9d3Yl5PW25AvlWAsEzu8Kx6K6g82w9ph++d9O6+UR8AuNyJNffPPk03qFrW5 ZDJxCsg1ZDOUA5elZf2lovXnwrnDhVjjYjT6RXUNE2c3X8LesY8Q6YctAYZ9r8/8aC0y 4qs974Amq/u2Oma2MMvgkp8VHfbybxoozhZQn+4MtnoJeokXTlqRnpBDgtXajOchIHtO rDcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=gI3GIGM6; spf=softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id j15-20020aa78dcf000000b004f3ee536ec6si553015pfr.95.2022.03.02.16.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 16:47:14 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=gI3GIGM6; spf=softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 319D7C5D91; Wed, 2 Mar 2022 16:07:39 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230023AbiCCAIV (ORCPT + 99 others); Wed, 2 Mar 2022 19:08:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230340AbiCCAIU (ORCPT ); Wed, 2 Mar 2022 19:08:20 -0500 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41728BDE5D; Wed, 2 Mar 2022 16:07:36 -0800 (PST) Received: by fieldses.org (Postfix, from userid 2815) id 9285572C6; Wed, 2 Mar 2022 19:07:35 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 9285572C6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1646266055; bh=+2OkF/NbJLCsAX1YGMh/jwrJmXkW2FAPJw5PAYnoPYc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gI3GIGM6C0MEcPAy+bBBGMVcEZWZjctZ2+aCQVwNnLybLTBKOcX8Su1Q81IUdoOhE aVIL368KpDB+8n7SPCKG0VDpawfDnHrD9i6L+u2Tf51NAMpjLqk39a1NKLXQChlbYY gKzE0bQIoMk5c0ggIZ/khQmfMZznjPprOkfReSRk= Date: Wed, 2 Mar 2022 19:07:35 -0500 From: "J. Bruce Fields" To: Josef Bacik Cc: linux-fsdevel , linux-nfs@vger.kernel.org, Chuck Lever Subject: Re: nfs generic/373 failure after "fs: allow cross-vfsmount reflink/dedupe" Message-ID: <20220303000735.GA21944@fieldses.org> References: <20220301184221.371853-1-amir73il@gmail.com> <20220302065952.GE3927073@dread.disaster.area> <20220302082658.GF3927073@dread.disaster.area> <20220302211226.GG3927073@dread.disaster.area> <20220302220450.GD10757@fieldses.org> <20220302224250.GF10757@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, Mar 02, 2022 at 06:45:12PM -0500, Josef Bacik wrote: > On Wed, Mar 02, 2022 at 05:42:50PM -0500, J. Bruce Fields wrote: > > On Wed, Mar 02, 2022 at 05:26:08PM -0500, Josef Bacik wrote: > > > On Wed, Mar 02, 2022 at 05:04:50PM -0500, J. Bruce Fields wrote: > > > > I started seeing generic/373 fail on recent linux-next in NFS testing. > > > > > > > > Bisect lands it on aaf40970b1d0 "fs: allow cross-vfsmount > > > > reflink/dedupe". > > > > > > > > The test fails because a clone between two mounts is expected to fail, > > > > and no longer does. > > > > > > > > In my setup both mounts are nfs mounts. They are mounts of different > > > > exports, and the exports are exports of different filesystems. So it > > > > does make sense that the clone should fail. > > > > > > > > I see the NFS client send a CLONE rpc to the server, and the server > > > > return success. That seems wrong. > > > > > > > > Both exported filesystems are xfs, and from the code it looks like the > > > > server calls vfs_clone_file_range(), which ends up calling > > > > xfs_file_remap_range(). > > > > > > > > Are we missing a check now in that xfs case? > > > > > > > > I haven't looked any more closely at what's going on, so I could be > > > > missing something. > > > > > > > > > > Yeah there's a few fstests that test this functionality that need to be removed, > > > I have patches pending for this in our fstests staging tree (since we run > > > fstests nightly on our tree) > > > > > > https://github.com/btrfs/fstests/tree/staging > > > > > > Right now the patches just remove the tests from auto since that's what we run, > > > I'll remove them properly once the patch lands in linus. Thanks, > > > > So, out of curiosity, what is xfs doing in this case? These are two > > filesystems on separate partitions, is it falling back on a read/write > > loop or something? > > I don't think so? I'm actually kind of confused, because nfsd does > vfs_clone_file_range, and the only place I messed with for CLONE was > ioctl_clone_file, so the patch changed literally nothing, unless you aren't > using nfsd for the server? > > And if they are in fact two different file systems the i_sb != i_sb of the > files, so there's something pretty strange going on here, my patch shouldn't > affect your setup. Thanks, Sorry, took me a minute to understand, myself: It's actually only the client behavior that changed. Previously the client would reject an attempt to clone across filesystems, so the server never saw such a request. After this patch, the client will go ahead and send the CLONE. (Which, come to think of it, is probably the right thing for the client to do.) So the server's probably always had a bug, and this just uncovered it. I'd be curious what the consequences are. And where the check should be (above or below vfs_clone_file_range()?). --b.