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

[Jan Kara <jack@suse.cz>]

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.

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.

								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