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>,
Amir Goldstein <amir73il@gmail.com>
Subject: Re: Shameless plug for the FS Track at LPC next week!
Date: Fri, 17 Sep 2021 11:38:38 +0200 [thread overview]
Message-ID: <20210917093838.GC6547@quack2.suse.cz> (raw)
In-Reply-To: <20210917083608.GB6547@quack2.suse.cz>
On Fri 17-09-21 10:36:08, Jan Kara wrote:
> Let me also post Amir's thoughts on this from a private thread:
And now I'm actually replying to Amir :-p
> On Fri 17-09-21 10:30:43, Jan Kara wrote:
> > 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.
>
> I think that legacy projid semantics might not be a perfect fit for
> container isolation requirements. I added project quota support to docker
> at the time because it was handy and it did the job of limiting and
> querying disk usage of containers with an overlayfs storage driver.
>
> With btrfs storage driver, subvolumes are used to create that isolation.
> The TREE_ID proposal [1] got me thinking that it is not so hard to
> implement "tree id" as an extention or in addition to project id.
>
> The semantics of "tree id" would be:
> 1. tree id is a quota entity accounting inodes and blocks
> 2. tree id can be changed only on an empty directory
> 3. tree id can be set to TID only if quota inode usage of TID is 0
> 4. tree id is always inherited from parent
> 5. No rename() or link() across tree id (clone should be possible)
>
> AFAIK btrfs subvol meets all the requirements of "tree id".
>
> Implementing tree id in ext4/xfs could be done by adding a new field to
> inode on-disk format and a new quota entity to quota on-disk format and
> quotatools.
>
> An alternative simpler way is to repurpose project id and project quota:
> * Add filesystem feature projid-is-treeid
> * The feature can be enabled on fresh mkfs or after fsck verifies "tree id"
> rules are followed for all usage of projid
> * Once the feature is enabled, filesystem enforces the new semantics
> about setting projid and projid_inherit
>
> This might be a good option if there is little intersection between
> systems that need to use the old project semantics and systems
> that would rather have the tree id semantics.
Yes, I actually think that having both tree-id and project-id on a
filesystem would be too confusing. And I'm not aware of realistic usecases.
I've heard only of people wanting current semantics (although these we more
of the kind: "sometime in the past people used the feature like this") and
the people complaining current semantics is not useful for them. This was
discussed e.g. in ext4 list [2].
> I think that with the "tree id" semantics, the user_ns/idmapped
> questions become easier to answer.
> Allocating tree id ranges per userns to avoid exhausting the tree id
> namespace is a very similar problem to allocating uids per userns.
It still depends how exactly tree ids get used - if you want to use them to
limit space usage of a container, you still have to forbid changing of tree
ids inside the container, don't you?
> [1] https://lore.kernel.org/linux-fsdevel/162848132775.25823.2813836616908535300.stgit@noble.brown/
[2] https://lore.kernel.org/linux-ext4/20200428153228.GB6426@quack2.suse.cz
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2021-09-17 9:39 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
2021-09-17 8:36 ` Jan Kara
2021-09-17 9:38 ` Jan Kara [this message]
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=20210917093838.GC6547@quack2.suse.cz \
--to=jack@suse.cz \
--cc=amir73il@gmail.com \
--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).