Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4853797ybe; Mon, 9 Sep 2019 16:03:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqySZpAB4g2+b3VY/Id6EHPEGH+FVfLUQ5K8wkO4jL4Zh+nrJuDd45071tqXj8fDJtCJ++7D X-Received: by 2002:a05:6402:3055:: with SMTP id bu21mr25431911edb.158.1568070209172; Mon, 09 Sep 2019 16:03:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568070209; cv=none; d=google.com; s=arc-20160816; b=ezyYy+PjJxYmWlKmv76BEXCSJnnWIOtyI/OJitUoCt6Q5RM1/kbNJeS4HT2geDCMgI TAmXPnDxjZGMqHRll6MmvJWeb+vUhrRKhX+hbMXLN+hjkOlhUlWW5Qxn5Uc16IfEMny0 BarYFtiKwJzNSFO5XNBByuqEq//U52fs3cm8EMPVUojB+5goT6K3oB6mGeb2G3KwvFxl RxfqurKzQs0VEx7DNhSib1XewiFVbYqACNy5Ij4uqk7fhFSkMw6C1EzMUlAqE8nlrauj xRelQ3tDBjF4g7KiuNEIPLoT16F7SEAe2/5wBv+EDq/CVhYXuykHwtxreWQ7dieCMMI5 biNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=zuepeCg5zzZ+GW2XWubVPXaz62DDAbV7bFYr+Y1aMGQ=; b=gAwsM4uyiZxczEy+fMqWGYdijbOBEJjXw/nXbLR7Ndo4afNzq/xUkN/e1JDguOe1M0 qzaRLNANSQzlIp8iq8REfKqRwxJMwysv2hR23EkhoHsMRs8yW3yjh2k97Lq+lmBcBOdN JM+chvi2ARfL/0U0QVv313HYIcRWpMZRhB+L1/mV/CuriqWGRWUZstF7JD125rPr9bcz 4QAUswdRwnMe5e4paLzEl/IgST7xzO2zXNyixhU/URvWfdYsF4xrld3HKCHE7LPaDsR+ Zjp2FNJINks7GBFmg8dSR2aLk1HhNvsZt/tHAlgL7udj3uaUj0TqNTnWSxXszsDsYf5h zf4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=k6UPqNn+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l27si8292025ejg.374.2019.09.09.16.03.05; Mon, 09 Sep 2019 16:03:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=k6UPqNn+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390197AbfIILF5 (ORCPT + 99 others); Mon, 9 Sep 2019 07:05:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:46458 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729692AbfIILF5 (ORCPT ); Mon, 9 Sep 2019 07:05:57 -0400 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DCDBB206A5; Mon, 9 Sep 2019 11:05:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568027156; bh=5pLtNhWjUzk4shrDRq2YPZNtxpgUnPEI/ImOsolN2yk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=k6UPqNn+dI17Ewt5HeMWR5STQJsha9lV3+KMjLJlP4woM+rbSX2xTt0ZJoLW+aahT WZ5RRdrGkpxP49+04gipER2t6CDbloFNX0HW93pCyiKwCsFjtTLlZNXjujBOfgjz+p tn0vrNHFdFMqDfKxFxyzuVRfYVd0CkSferH9TLjY= Message-ID: <30c007d0c735cd37121e3c2264c1ec3cfdcfd89f.camel@kernel.org> Subject: Re: [PATCH v2] ceph: allow object copies across different filesystems in the same cluster From: Jeff Layton To: Luis Henriques , Sage Weil , Ilya Dryomov Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 09 Sep 2019 07:05:54 -0400 In-Reply-To: <3f838e42a50575595c7310386cf698aca8f89607.camel@kernel.org> References: <87k1ahojri.fsf@suse.com> <20190909102834.16246-1-lhenriques@suse.com> <3f838e42a50575595c7310386cf698aca8f89607.camel@kernel.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2019-09-09 at 06:35 -0400, Jeff Layton wrote: > On Mon, 2019-09-09 at 11:28 +0100, Luis Henriques wrote: > > OSDs are able to perform object copies across different pools. Thus, > > there's no need to prevent copy_file_range from doing remote copies if the > > source and destination superblocks are different. Only return -EXDEV if > > they have different fsid (the cluster ID). > > > > Signed-off-by: Luis Henriques > > --- > > fs/ceph/file.c | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > Hi, > > > > Here's the patch changelog since initial submittion: > > > > - Dropped have_fsid checks on client structs > > - Use %pU to print the fsid instead of raw hex strings (%*ph) > > - Fixed 'To:' field in email so that this time the patch hits vger > > > > Cheers, > > -- > > Luis > > > > diff --git a/fs/ceph/file.c b/fs/ceph/file.c > > index 685a03cc4b77..4a624a1dd0bb 100644 > > --- a/fs/ceph/file.c > > +++ b/fs/ceph/file.c > > @@ -1904,6 +1904,7 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off, > > struct ceph_inode_info *src_ci = ceph_inode(src_inode); > > struct ceph_inode_info *dst_ci = ceph_inode(dst_inode); > > struct ceph_cap_flush *prealloc_cf; > > + struct ceph_fs_client *src_fsc = ceph_inode_to_client(src_inode); > > struct ceph_object_locator src_oloc, dst_oloc; > > struct ceph_object_id src_oid, dst_oid; > > loff_t endoff = 0, size; > > @@ -1915,8 +1916,17 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off, > > > > if (src_inode == dst_inode) > > return -EINVAL; > > - if (src_inode->i_sb != dst_inode->i_sb) > > - return -EXDEV; > > + if (src_inode->i_sb != dst_inode->i_sb) { > > + struct ceph_fs_client *dst_fsc = ceph_inode_to_client(dst_inode); > > + > > + if (ceph_fsid_compare(&src_fsc->client->fsid, > > + &dst_fsc->client->fsid)) { > > + dout("Copying object across different clusters:"); > > + dout(" src fsid: %pU dst fsid: %pU\n", > > + &src_fsc->client->fsid, &dst_fsc->client->fsid); > > + return -EXDEV; > > + } > > + } > > Just to be clear: what happens here if I mount two entirely separate > clusters, and their OSDs don't have any access to one another? Will this > fail at some later point with an error that we can catch so that we can > fall back? > Duh, sorry I asked before I had a cup of coffee this morning. The whole point is to skip that case. That said...I wonder if it's possible to have an fsid collision across two separate clusters and this fail to catch that case? Aren't these things just allocated via a simple counter increment? Probably not worth worrying about overmuch, but might be good to understand what would happen in that case if only to field mailing list reports. Other than that, this looks fine, modulo Ilya's comment about the two dout messages. > > > if (ceph_snap(dst_inode) != CEPH_NOSNAP) > > return -EROFS; > > > > @@ -1928,7 +1938,7 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off, > > * efficient). > > */ > > > > - if (ceph_test_mount_opt(ceph_inode_to_client(src_inode), NOCOPYFROM)) > > + if (ceph_test_mount_opt(src_fsc, NOCOPYFROM)) > > return -EOPNOTSUPP; > > > > if ((src_ci->i_layout.stripe_unit != dst_ci->i_layout.stripe_unit) || > > @@ -2044,7 +2054,7 @@ static ssize_t __ceph_copy_file_range(struct file *src_file, loff_t src_off, > > dst_ci->i_vino.ino, dst_objnum); > > /* Do an object remote copy */ > > err = ceph_osdc_copy_from( > > - &ceph_inode_to_client(src_inode)->client->osdc, > > + &src_fsc->client->osdc, > > src_ci->i_vino.snap, 0, > > &src_oid, &src_oloc, > > CEPH_OSD_OP_FLAG_FADVISE_SEQUENTIAL | -- Jeff Layton