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@xxxxxxxx> > SUSE Labs, CR >
