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@xxxxxxxxxxxxxx Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
