All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Henriques <lhenriques@suse.com>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: Gregory Farnum <gfarnum@redhat.com>,
	"Yan, Zheng" <zyan@redhat.com>, Sage Weil <sage@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel <ceph-devel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Hendrik Peyerl <hpeyerl@plusline.net>
Subject: Re: [PATCH v2 2/2] ceph: quota: fix quota subdir mounts
Date: Mon, 18 Mar 2019 10:55:45 +0000	[thread overview]
Message-ID: <87lg1czc26.fsf@suse.com> (raw)
In-Reply-To: <CAAM7YAmt+OS8=ycPrtLLe_FqeD2F_szdkShNAPA49FOPoJd+Gg@mail.gmail.com> (Zheng Yan's message of "Mon, 18 Mar 2019 17:12:39 +0800")

"Yan, Zheng" <ukernel@gmail.com> writes:

> On Mon, Mar 18, 2019 at 5:06 PM Gregory Farnum <gfarnum@redhat.com> wrote:
>>
>> On Mon, Mar 18, 2019 at 2:32 PM Yan, Zheng <ukernel@gmail.com> wrote:
>> > After reading the code carefully. I feel a little uncomfortable with
>> > the "lookup_ino" in get_quota_realm.  how about populating directories
>> > above the 'mount subdir' during mounting (similar to cifs_get_root ).

Wouldn't it be a problem if the directory layout (or, in this case, the
snaprealm layout) change during the mount lifetime?  In that case we
would need to do this lookup anyway.

>>
>> Isn't that going to be a problem for any clients which have
>>restricted filesystem access permissions? They may not be able to see
>>all the directories above their mount point.  -Greg
>
> using lookup_ino to get inode above the "mount subdir" has the same problem
>

In this case I believe we get an -EPERM from the MDS.  And then the
client simply falls back to the 'default' behaviour, which is to allow
the user to create/write to files as if there were no quotas set.

Cheers,
-- 
Luis

WARNING: multiple messages have this Message-ID (diff)
From: Luis Henriques <lhenriques@suse.com>
To: "Yan\, Zheng" <ukernel@gmail.com>
Cc: Gregory Farnum <gfarnum@redhat.com>, "Yan\,
	Zheng" <zyan@redhat.com>, Sage Weil <sage@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	ceph-devel <ceph-devel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Hendrik Peyerl <hpeyerl@plusline.net>
Subject: Re: [PATCH v2 2/2] ceph: quota: fix quota subdir mounts
Date: Mon, 18 Mar 2019 10:55:45 +0000	[thread overview]
Message-ID: <87lg1czc26.fsf@suse.com> (raw)
In-Reply-To: <CAAM7YAmt+OS8=ycPrtLLe_FqeD2F_szdkShNAPA49FOPoJd+Gg@mail.gmail.com> (Zheng Yan's message of "Mon, 18 Mar 2019 17:12:39 +0800")

"Yan, Zheng" <ukernel@gmail.com> writes:

> On Mon, Mar 18, 2019 at 5:06 PM Gregory Farnum <gfarnum@redhat.com> wrote:
>>
>> On Mon, Mar 18, 2019 at 2:32 PM Yan, Zheng <ukernel@gmail.com> wrote:
>> > After reading the code carefully. I feel a little uncomfortable with
>> > the "lookup_ino" in get_quota_realm.  how about populating directories
>> > above the 'mount subdir' during mounting (similar to cifs_get_root ).

Wouldn't it be a problem if the directory layout (or, in this case, the
snaprealm layout) change during the mount lifetime?  In that case we
would need to do this lookup anyway.

>>
>> Isn't that going to be a problem for any clients which have
>>restricted filesystem access permissions? They may not be able to see
>>all the directories above their mount point.  -Greg
>
> using lookup_ino to get inode above the "mount subdir" has the same problem
>

In this case I believe we get an -EPERM from the MDS.  And then the
client simply falls back to the 'default' behaviour, which is to allow
the user to create/write to files as if there were no quotas set.

Cheers,
-- 
Luis

  reply	other threads:[~2019-03-18 10:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12 14:20 [PATCH v2 0/2] fix quota subdir mounts Luis Henriques
2019-03-12 14:20 ` [PATCH v2 1/2] ceph: factor out ceph_lookup_inode() Luis Henriques
2019-03-12 14:20 ` [PATCH v2 2/2] ceph: quota: fix quota subdir mounts Luis Henriques
2019-03-18  9:01   ` Yan, Zheng
2019-03-18  9:05     ` Gregory Farnum
2019-03-18  9:12       ` Yan, Zheng
2019-03-18 10:55         ` Luis Henriques [this message]
2019-03-18 10:55           ` Luis Henriques
2019-03-18 11:19           ` Gregory Farnum
2019-03-18 12:55           ` Yan, Zheng
2019-03-18 13:06   ` Yan, Zheng
2019-03-19 16:42     ` Luis Henriques
2019-03-19 16:42       ` Luis Henriques

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lg1czc26.fsf@suse.com \
    --to=lhenriques@suse.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=gfarnum@redhat.com \
    --cc=hpeyerl@plusline.net \
    --cc=idryomov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sage@redhat.com \
    --cc=ukernel@gmail.com \
    --cc=zyan@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.