Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3570632ybl; Sun, 8 Dec 2019 18:14:35 -0800 (PST) X-Google-Smtp-Source: APXvYqzx6BcafhJJx9U0AiQ2wkkYXtf6lIQF3dKWOM9tRpx3Tey3/rRm0Bk0i6+Gy8CHM/bDLEeC X-Received: by 2002:a9d:1425:: with SMTP id h34mr19836740oth.166.1575857675480; Sun, 08 Dec 2019 18:14:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575857675; cv=none; d=google.com; s=arc-20160816; b=gqDK78/mSMOrGGg4VZiiNq+gyDZMmvHwMj745vq8SQ73owLS7sVnutcFZJUu3sYBTv zjShWutMvNO9VGU25/A8MVlPpIGiWGaB3s8jQ59wA5fdEwJltuug5QQhA2bM+omnlBeK c6Fauu0pQpCFg7hIGbgOS5IG6sJr9giOPotao6XA3E2ykTBLusF+oPJC1dxcr15bvC8k +I5MeYGlMyKdIw6Tc+Ht1c/BoDMiOvancy6FKOOVrSUSiVtlpnenJ9FGPDqGUXJLxXM0 5pgchY9H+BdDY45ds1CeH1BJ1YmZwWVFdEpWUn5AVkrCu1Z79rWcg6NVNl0iXmnumESh gxFg== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=k15R5nnH7ejDpMt2qDC/YjWGHq/27T3NqR985G0b1io=; b=WqaLCvqFzyxR/eCN6m5jLBfnsJBCIbsT+RCWg/PKUp43kcmbdodVaD/mQUiTmQGoqU FE5iAlcnqlzyhUqAeHTHRaBJeln4Ys00pPlqydhE4YnQDMETFSpUNRvVCyAoKVsz89L0 OksyVUQ1wDZD1lmyTig+ffOQ8psnHQ8fQQlmCapD929brdGtWfV6RxvmcY0yRTyGUH1S hKSg9x2okwbrkUsodZwgxGxjlerkIEUZZb0TYZ7eYpCjp+YtPTH8oOz4Nw2xeIs4ggmj PrOiFVHcDwRnE9IYHYEBKLCUE+RhQ+SokkED+3YUaSTtBcXnEaot5dYOlNCnSgKqYFiJ h34A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=e0YvdE3p; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x21si11320928oif.250.2019.12.08.18.14.22; Sun, 08 Dec 2019 18:14:35 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=e0YvdE3p; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726834AbfLICNz (ORCPT + 99 others); Sun, 8 Dec 2019 21:13:55 -0500 Received: from mail-il1-f193.google.com ([209.85.166.193]:40566 "EHLO mail-il1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726635AbfLICNz (ORCPT ); Sun, 8 Dec 2019 21:13:55 -0500 Received: by mail-il1-f193.google.com with SMTP id b15so11336148ila.7; Sun, 08 Dec 2019 18:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=k15R5nnH7ejDpMt2qDC/YjWGHq/27T3NqR985G0b1io=; b=e0YvdE3pADvK2Ktnt0flJw9zLH2RNpK3dJowZUsSejzeefqwu7BqYYIeAY01iQt7cn Z9s/Gk0ybxsjTSfOItKoypebt/D1cSPOPwVd1PBfSvFvNPpUph4qoH1IcXYJyDaJhRTL j5FOw6lY1ggO3hL/aExyG+zCF6bG3Lu5ACeuK0YxQfJFk3r3dK473a4gLDcOacqGeiuU yqg3OHtgpPy7qZ/Rl9BVaHBCJZkqKBh5tZl5FLFoHHAc0J05ijxNFI3Oi5DNRUf7xvDc yAI4qM2ofJdINtkmivJhdalTyrdIO8v8rkoTQQ5/9xCv2gECnlcpbO/SOAnu+eRIHRO1 d8zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k15R5nnH7ejDpMt2qDC/YjWGHq/27T3NqR985G0b1io=; b=B8rVOxu+ng1LiM2Hk4C/QSePR+ZPxWb6lEMxQp5QBrMQ+LgUE4YMyBHSfuZnqUkI+z lz3KlzQUal15K8YlHIAEaisKGrF7O4w1qqzo7Tr7grSCnnQihlIOUNzWttkbwTL+nTS7 nJcwhR4pt5AZyHKzbKjP20pJepiJ/7OTv+R6a0RyFDw7fqTNDjjIG+EdloCU1yFMicKy 6bMIh4bhI4WUWWSUvXCvYzDEKEsm5qUf0v3X0sp7uj3lnwEGkdrcujw3APnXHHRqzxuD Th2q9uJ0P6MY7gjOK5SpHPA/vwI5TTa202fNE/WYMA0/35DNsuUaqQvsBiR95WZ6XjJg 6a5g== X-Gm-Message-State: APjAAAWvFzfnmKPM28BwFV3/dbrdyhGwIZRPRWUd5ZF8QqMx+r5ySxzH eZzS4wbjG4ww6P2lQKdEFEyclRoDU0nwSpkqaJ4= X-Received: by 2002:a92:6a08:: with SMTP id f8mr24730721ilc.27.1575857634060; Sun, 08 Dec 2019 18:13:54 -0800 (PST) MIME-Version: 1.0 References: <20191204031005.2638-1-gmayyyha@gmail.com> <20191204103629.GA22244@hermes.olymp> <20191205102433.GA5758@hermes.olymp> In-Reply-To: <20191205102433.GA5758@hermes.olymp> From: Yanhu Cao Date: Mon, 9 Dec 2019 10:13:41 +0800 Message-ID: Subject: Re: [PATCH] ceph: check set quota operation support before syncing setxattr. To: Luis Henriques Cc: jlayton@kernel.org, sage@redhat.com, idryomov@gmail.com, ceph-devel , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 5, 2019 at 6:24 PM Luis Henriques wrote: > > On Thu, Dec 05, 2019 at 10:42:46AM +0800, Yanhu Cao wrote: > > On Wed, Dec 4, 2019 at 6:36 PM Luis Henriques wro= te: > > > > > > On Wed, Dec 04, 2019 at 11:10:05AM +0800, Yanhu Cao wrote: > > > > Environment > > > > ----------- > > > > ceph version: 12.2.* > > > > kernel version: 4.19+ > > > > > > > > setfattr quota operation actually sends op to MDS, and settings > > > > effective. but kclient outputs 'Operation not supported'. This may = confuse > > > > users' understandings. > > > > > > What exactly do you mean by "settings effective"? There have been > > > changes in the way CephFS quotas work in mimic and, if you're using a > > > Luminous cluster (12.2.*) the kernel client effectively does *not* > > > support quotas -- you'll be able to exceed the quotas you've tried to > > > set because the client won't be checking the limits. Thus, -EOPNOTSU= PP > > > seems appropriate for this scenario. > > > > > > I guess that the confusing part is that the xattr is actually set in > > > that case, but the kernel client won't be able to use it to validate > > > quotas in the filesystem tree because realms won't be created. > > > > > Yes. we use kcephfs+nfs for CentOS6.*, it does not support ceph-fuse(12= .2.*). > > The operating system of other applications is CentOS7.*, which uses > > ceph-fuse and can get quota settings set by kclient. > > Ok, so if I understand correctly, you're setting quotas with the kernel > client but actually using ceph-fuse on CentOS7 (I'm assuming a Luminous > cluster). This should work fine for the fuse-client, but please note > that the kernel client will not respect quotas. Yes. do with fuse-client now. > > Anyway, the ideal solution for this would be for the kernel to not set > the xattr if the cluster doesn't support the new quotas format > introduced in Mimic. Unfortunately, the only way we have to find that > out is to set the xattr and see if we get a snap_realm. Therefore, I think that if kclient is incompatible with the ceph version, logically, op should not be sent to MDS. Thanks. BRs > > Cheers, > -- > Lu=C3=ADs > > > > > Thanks. > > BRs > > > > > Cheers, > > > -- > > > Lu=C3=ADs > > > > > > > > If the kernel version and ceph version are not compatible, should c= heck > > > > quota operations are supported first, then do sync_setxattr. > > > > > > > > reference: https://docs.ceph.com/docs/master/cephfs/quota/ > > > > > > > > Signed-off-by: Yanhu Cao > > > > --- > > > > fs/ceph/xattr.c | 6 ++++-- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c > > > > index cb18ee637cb7..189aace75186 100644 > > > > --- a/fs/ceph/xattr.c > > > > +++ b/fs/ceph/xattr.c > > > > @@ -1132,8 +1132,8 @@ int __ceph_setxattr(struct inode *inode, cons= t char *name, > > > > "during filling trace\n", inode); > > > > err =3D -EBUSY; > > > > } else { > > > > - err =3D ceph_sync_setxattr(inode, name, value, size, = flags); > > > > - if (err >=3D 0 && check_realm) { > > > > + err =3D 0; > > > > + if (check_realm) { > > > > /* check if snaprealm was created for quota i= node */ > > > > spin_lock(&ci->i_ceph_lock); > > > > if ((ci->i_max_files || ci->i_max_bytes) && > > > > @@ -1142,6 +1142,8 @@ int __ceph_setxattr(struct inode *inode, cons= t char *name, > > > > err =3D -EOPNOTSUPP; > > > > spin_unlock(&ci->i_ceph_lock); > > > > } > > > > + if (err =3D=3D 0) > > > > + err =3D ceph_sync_setxattr(inode, name, value= , size, flags); > > > > } > > > > out: > > > > ceph_free_cap_flush(prealloc_cf); > > > > -- > > > > 2.21.0 (Apple Git-122.2) > > > >