Re: [PATCH 1/2] shmem: implement user/group quota support for tmpfs

[Jan Kara <jack@suse.cz>]

On Tue 08-11-22 08:25:22, Darrick J. Wong wrote:
> On Tue, Nov 08, 2022 at 02:30:09PM +0100, Lukas Czerner wrote:
> > diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst
> > index 0408c245785e..9c4f228ef4f3 100644
> > --- a/Documentation/filesystems/tmpfs.rst
> > +++ b/Documentation/filesystems/tmpfs.rst
> > @@ -86,6 +86,18 @@ use up all the memory on the machine; but enhances the scalability of
> >  that instance in a system with many CPUs making intensive use of it.
> >  
> >  
> > +tmpfs also supports quota with the following mount options
> > +
> > +========  =============================================================
> > +quota     Quota accounting is enabled on the mount. Tmpfs is using
> > +          hidden system quota files that are initialized on mount.
> > +          Quota limits can quota enforcement can be enabled using
> > +          standard quota tools.
> > +usrquota  Same as quota option. Exists for compatibility reasons.
> > +grpquota  Same as quota option. Exists for compatibility reasons.
> 
> I guess this is following ext* where group and user quota cannot be
> enabled individually, nor is there a 'noenforce' mode?

Well, in ext4 enforcement of user and group quotas can be enabled
separately. usrquota enables enforcement of user quotas, grpquota enables
enforcement of group quotas. Quota usage tracking depends on the enabled
filesystem features and there you are correct ext4 either tracks both user
& group usage or none.  OTOH project quota tracking can be selected
separately.  Frankly, I don't see a great reason to not allow user/group
quotas to be tracked independently when we already have all three mount
options.

I agree the noenforce mode for tmpfs does not make a lot of sense.

> > +		shmem_quota_write_inode(inode, type, (const char *)&qinfo,
> > +					sizeof(qinfo), sizeof(qheader));
> > +		shmem_quota_write_inode(inode, type, 0,
> > +					QT_TREEOFF * QUOTABLOCK_SIZE,
> > +					QUOTABLOCK_SIZE);
> > +
> > +		shmem_set_inode_flags(inode, FS_NOATIME_FL | FS_IMMUTABLE_FL);
> > +
> > +		err = dquot_load_quota_inode(inode, type, QFMT_VFS_V1,
> 
> I wonder, what's the difference between quota v1 and v2?  Wouldn't we
> want the newer version?

So this is a naming catch I've introduced many years ago :-| QFMT_VFS_V1 is
the newest quota format we support and is implemented in
fs/quota/quota_v2.c

> > @@ -353,7 +590,6 @@ static void shmem_recalc_inode(struct inode *inode)
> >  	freed = info->alloced - info->swapped - inode->i_mapping->nrpages;
> >  	if (freed > 0) {
> >  		info->alloced -= freed;
> > -		inode->i_blocks -= freed * BLOCKS_PER_PAGE;
> 
> I guess the quotaops helpers take care of the i_blocks updates now?

Yes, dquot_alloc_space() takes care of inode->i_blocks update.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR