[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKPOu+8VdbrH6pc3vRgh+FnW=kzj1s6TYUEuQQGM_xKmpazXGg@mail.gmail.com>
Date: Thu, 12 Sep 2024 08:36:03 +0200
From: Max Kellermann <max.kellermann@...os.com>
To: Xiubo Li <xiubli@...hat.com>
Cc: Patrick Donnelly <pdonnell@...hat.com>, idryomov@...il.com, ceph-devel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] fs/ceph/quota: ignore quota with CAP_SYS_RESOURCE
On Thu, Sep 12, 2024 at 4:00 AM Xiubo Li <xiubli@...hat.com> wrote:
> > If you want to upstream this, the appropriate change would go in
> > ceph.git as a new cephx capability (not cephfs capability) for the
> > "mds" auth cap that would allow a client with root (or
> > CAP_SYS_RESOURCE) to bypass quotas. I would support merging such a
> > patch (and the corresponding userspace / kernel client changes).
> >
> Yeah, Patrick is correct. This really will by pass the protocols and
> restrictions in cephfs and introduces inconsistency. By adding a new
> cephx caps we can broadcast this to all the users or clients.
I don't get any of this, please help me understand.
1. What protocol restrictions are being bypassed?
All the (user) documentation I found on docs.deph.com and on the
RedHat website about Ceph quotas is very unspecific, but it mentions
that clients can write over quota for up to 10 seconds - so writing
over quota, while not desirable, is something that can happen in
normal operation and the resulting state must be well-defined.
I found no protocol documentation at all about cephfs quotas. Where
can I find it?
2. What inconsistency is being introduced? Do you mean that the actual
stored bytes are bigger than the quota limit? If yes, then how is this
different from setting a quota limit on a directory that is already
above this new limit?
3. What is the worst that could happen if I ignore your advice and
just keep my patch in our kernel fork? (i.e. without introducing any
cephx caps)
Max
Powered by blists - more mailing lists