Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2114134imc; Tue, 12 Mar 2019 07:21:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4NrNbQ1Is3J2f9Z2gvG74PBsF5mwsn8vZMBE1ny8u5BRPH+YNZywJDj+aZJIctkrpAsNa X-Received: by 2002:a63:780e:: with SMTP id t14mr17750058pgc.276.1552400465289; Tue, 12 Mar 2019 07:21:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552400465; cv=none; d=google.com; s=arc-20160816; b=YS+XEBKSkk0+Vr8VjfgHRYZNa8xbIHoGjJwLeRLA2+KXjXYsXXKiY3iUdxJekWRCx9 abHFFUP/kZoCApraoP3TG9CRcU0rPLrTxoZQzh9fwkLmLIqCxaKs6LLVt7T/PpodRHMH EI0NDffmWdAQ43moRUl+ooP9cD7arbhB0pDix/CFg/xeIO0k88d6egfynsaP3D+y55Vu PA46bo9ruWzmzEQT26aJ96Bu8v+nQxQSAFodx99s58nszhopptKDGQBxFstMfo6/LBPg pAyC/0MHqQxQFMtaMX7b7+i3M0gfA/popHMS/5XwigoVtH4v27pNUfXB/1p+bMyNIXzn d49A== 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 :message-id:date:subject:cc:to:from; bh=Twn8/wSNutsQzmgGT/y6DPoRBhdB89eizjxE7Q/PM4c=; b=r897CDtDS7Ei+YPR0JbvuuE5G+up8t3MIjIyz9oCKO1vsryDNCQeq7pQWBAwwTmLfJ 529do0hG09PNk44qGjsfwK6jIQzHzrj+LW1ibN06gWCOuGBryQ1Xr5duovVHWyJ9uvIX gITVkw4KTilHIDjEC9gmz6CfDcXmJKTGiG3OoPUvi7bxBgFRP32BkYNMuv+ICgX2jm1W clyHEOUZPUqn6NT2uZaSjmPNkWhfBAhGH5Swz3RcwNnlZ3soLGgWBYDGxgmv4/KCshpi /IyFrhYIFBm1b3cAyVsTF9hIAQjf3DZY02Ed9N11KDB/AhlV/yz44yoY/nxk6iZOZY6B /5iA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y4si8265436plk.30.2019.03.12.07.20.48; Tue, 12 Mar 2019 07:21:05 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726835AbfCLOUX (ORCPT + 99 others); Tue, 12 Mar 2019 10:20:23 -0400 Received: from mx2.suse.de ([195.135.220.15]:58428 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725894AbfCLOUW (ORCPT ); Tue, 12 Mar 2019 10:20:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 9B520B644; Tue, 12 Mar 2019 14:20:21 +0000 (UTC) From: Luis Henriques To: "Yan, Zheng" , Sage Weil , Ilya Dryomov Cc: ceph-devel@vger.kernel.org, linux-kernel@vger.kernel.org, Luis Henriques Subject: [PATCH v2 0/2] fix quota subdir mounts Date: Tue, 12 Mar 2019 14:20:17 +0000 Message-Id: <20190312142019.30936-1-lhenriques@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, As recently reported in the ceph-users mailing-list[1], the kernel client behaves differently from the fuse client regarding mounting subdirs where quotas are in effect. I've also created a bug to track this issue[2]. The following patches are a possible way of fixing this issue. The performance impact should be close to zero if the mount is done in the CephFS root inode. When we're mounting subdirs, we may have extra queries to the MDSs, depending on how many extra realms we'll need to loop through. Changes since v1: - Loop to free mdsc->quotarealms_inodes_list list was moved further down where it's not possible to race with insertions. This way there's no need to hold the spinlock anymore. - Clarified comments regarding the get_quota_realm function 'retry' parameter, both in the function itself and in function ceph_quota_is_same_realm, where that param is set to 'false' - Distinguish between 'realm->inode is NULL' and igrab failures, both in get_quota_realm and check_quota_exceeded Changes since RFC: The 1st patch hasn't been changed since the initial RFC. The 2nd patch has been refactored to include the following changes: - Zheng Yan's suggestions, i.e, move inode references from the realms to ceph_mds_client instance - It now also handles other cases where an MDS lookup may need to be performed: * statfs when there are quotas * renames, to forbid cross-quota renames [1] http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-February/033357.html [2] https://tracker.ceph.com/issues/38482 Cheers, -- Luís Luis Henriques (2): ceph: factor out ceph_lookup_inode() ceph: quota: fix quota subdir mounts fs/ceph/export.c | 14 +++++- fs/ceph/mds_client.c | 15 ++++++ fs/ceph/mds_client.h | 2 + fs/ceph/quota.c | 106 +++++++++++++++++++++++++++++++++++++++---- fs/ceph/super.h | 3 ++ 5 files changed, 129 insertions(+), 11 deletions(-)