linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: xfs <linux-xfs@vger.kernel.org>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: Shameless plug for the FS Track at LPC next week!
Date: Fri, 17 Sep 2021 10:30:43 +0200	[thread overview]
Message-ID: <20210917083043.GA6547@quack2.suse.cz> (raw)
In-Reply-To: <20210916013916.GD34899@magnolia>

Hi!

We did a small update to the schedule:

> Christian Brauner will run the second session, discussing what idmapped
> filesystem mounts are for and the current status of supporting more
> filesystems.

We have extended this session as we'd like to discuss and get some feedback
from users about project quotas and project ids:

Project quotas were originally mostly a collaborative feature and later got
used by some container runtimes to implement limitation of used space on a
filesystem shared by multiple containers. As a result current semantics of
project quotas are somewhat surprising and handling of project ids is not
consistent among filesystems. The main two contending points are:

1) Currently the inode owner can set project id of the inode to any
arbitrary number if he is in init_user_ns. It cannot change project id at
all in other user namespaces.

2) Should project IDs be mapped in user namespaces or not? User namespace
code does implement the mapping, VFS quota code maps project ids when using
them. However e.g. XFS does not map project IDs in its calls setting them
in the inode. Among other things this results in some funny errors if you
set project ID to (unsigned)-1.

In the session we'd like to get feedback how project quotas / ids get used
/ could be used so that we can define the common semantics and make the
code consistently follow these rules.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  parent reply	other threads:[~2021-09-17  8:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-16  1:39 Shameless plug for the FS Track at LPC next week! Darrick J. Wong
2021-09-16 12:08 ` [External] : " Chandan Babu R
2021-09-17 22:11   ` Dave Chinner
2021-09-17 23:50     ` Darrick J. Wong
2021-09-18 15:21       ` James Bottomley
2021-09-17  8:30 ` Jan Kara [this message]
2021-09-17  8:36   ` Jan Kara
2021-09-17  9:38     ` Jan Kara
2021-09-17 10:23       ` Amir Goldstein
2021-09-17 16:12         ` Darrick J. Wong
2021-09-17 23:15           ` Dave Chinner
2021-09-18  7:44             ` Alternative project ids and quotas semantics (Was: Shameless plug for the FS Track at LPC next week!) Amir Goldstein
2021-09-23  0:38               ` Dave Chinner

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=20210917083043.GA6547@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=djwong@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).