Re: [PATCH v2 1/3] quota: add quota in-memory format support

[Brian Foster <bfoster@redhat.com>]

On Wed, Nov 23, 2022 at 09:36:15AM +0100, Lukas Czerner wrote:
> On Tue, Nov 22, 2022 at 11:58:33PM -0800, Christoph Hellwig wrote:
> > On Tue, Nov 22, 2022 at 03:21:17PM +0100, Lukas Czerner wrote:
> > > > That seems like a good idea for memory usage, but I think this might
> > > > also make the code much simpler, as that just requires fairly trivial
> > > > quota_read and quota_write methods in the shmem code instead of new
> > > > support for an in-memory quota file.
> > > 
> > > You mean like the implementation in the v1 ?
> > 
> > Having now found it: yes.
> > 
> 
> Jan,
> 
> do you have any argument for this, since it was your suggestion?
> 
> I also think that the implementation is much simpler with in-memory
> dquots because we will avoid all the hassle with creating and
> maintaining quota file in a proper format. It's not just reads and
> writes it's the entire machinery befind it in quota_v2.c and quota_tree.c.
> 
> But it is true that even with only user modified dquots being
> non-reclaimable until unmount it could theoreticaly represent a
> substantial memory consumption. Although I do wonder if this problem
> is even real. How many user/group ids would you expect extremely heavy
> quota user would have the limits set for? 1k, 10k, million, or even
> more? Do you know?
> 

I don't know this code well enough to have a strong opinion on the v1
vs. v2 approach in general, but FWIW it does seem to me that the benefit
of v1 from a memory savings perspective is perhaps overstated. AFAICT,
tmpfs already pins inodes/denties (notably larger than dquots) in-core
for the lifetime of the inode, so it's not like we'll be saving much
memory from dquots that are actually in-use. I think this dquot memory
should be limited indirectly by the max inode restriction, as well.

That means the potential wastage is measured in dquots that are no
longer referenced, but have previously had a non-default quota limit set
by the admin, right? Even with the v1 approach, I don't think it's wise
to just push such otherwise unused dquots into swap space indefinitely.

Perhaps a reasonable approach to the memory usage issue is to just cap
the number of dquots that are allowed to have custom limits on tmpfs?
E.g., to echo Lukas above.. if there was a cap of something like 512-1k
custom quota limits, would that really be a problem for quota users on
tmpfs? Other users would still be covered by the default mount-time
limits. Of course, you could always make such a cap flexible as a % of
tmpfs size, or configurable via mount option, etc. Just a thought.

Brian

> -Lukas
> 
>