Re: [PATCH 0/2] [RFC] shmem: user and group quota support for tmpfs

[Lukas Czerner <lczerner@redhat.com>]

On Tue, Nov 08, 2022 at 06:43:26PM +0100, Jan Kara wrote:
> On Tue 08-11-22 14:30:08, Lukas Czerner wrote:
> > people have been asking for quota support in tmpfs many times in the past
> > mostly to avoid one malicious user, or misbehaving user/program to consume
> > all of the system memory. This has been partially solved with the size
> > mount option, but some problems still prevail.
> > 
> > One of the problems is the fact that /dev/shm is still generally unprotected
> > with this and another is administration overhead of managing multiple tmpfs
> > mounts and lack of more fine grained control.
> > 
> > Quota support can solve all these problems in a somewhat standard way
> > people are already familiar with from regular file systems. It can give us
> > more fine grained control over how much memory user/groups can consume.
> > Additionally it can also control number of inodes and with special quota
> > mount options introduced with a second patch we can set global limits
> > allowing us to replace the size mount option with quota entirely.
> > 
> > Currently the standard userspace quota tools (quota, xfs_quota) are only
> > using quotactl ioctl which is expecting a block device. I patched quota [1]
> > and xfs_quota [2] to use quotactl_fd in case we want to run the tools on
> > mount point directory to work nicely with tmpfs.
> > 
> > The implementation was tested on patched version of xfstests [3].
> > 
> > Thoughts?
> 
> Thanks for the work Lukas! I have one general note regarding this quota
> support: IMO it is pointless to try to retrofit how quota files work on
> block-based filesystems to tmpfs. All the bothering with converting between
> on-disk and in-mem representation, formatting of btree nodes is just
> pointless waste of CPU and code.

Hi Jan,

you're right and I did have some thoughts along the same lines. I wasn't
sure how the idea of quota on tmpfs is going to be received and so I
wanted to limit the scope of changes and make my job easier.
It works well as a proof-of-concept but I agree that storing quota data
in some in-memory representation is an ultimate way to go for tmpfs.

> 
> I think much simpler approach would be to keep some internal rbtree with
> quota structures carrying struct mem_dqblk and id. Then your .acquire_dquot
> handler will fill in quota information from the structure and
> .release_dquot will copy new data into the structure.
> 
> So basically all operations you'd need to provide in your implementation
> are .acquire_dquot, .release_dquot, and .get_next_id. And then you'll
> probably need to define new quota format with .read_file_info callback
> filling in some limits of the format (and some other stub callbacks doing
> nothing). If there's too much boilerplate code doing nothing, we can have a
> look into making quota core more clever to make life simpler for in-memory
> filesystems (hidden behind something like DQUOT_QUOTA_IN_MEMORY flag in
> struct quota_info) but currently I don't think it will be too bad.

Thanks for the insight and suggestions. I'll see what I can do with this
and prepare v2.

Thanks!
-Lukas

> 
> 								Honza
> 
> > [1] https://github.com/lczerner/quota/tree/quotactl_fd_support
> > [2] https://github.com/lczerner/xfsprogs/tree/quotactl_fd_support
> > [3] https://github.com/lczerner/xfstests/tree/tmpfs_quota_support
> > 
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
>