On Fri 25-11-22 10:30:10, Lukas Czerner wrote:
> On Wed, Nov 23, 2022 at 06:07:39PM +0100, Jan Kara wrote:
> > On Mon 21-11-22 15:28:52, Lukas Czerner wrote:
> > Instead of this I'd define:
> >
> > struct shmem_dquot {
> > struct rb_node node;
> > qid_t id;
> > qsize_t bhardlimit;
> > qsize_t bsoftlimit;
> > qsize_t ihardlimit;
> > qsize_t isoftlimit;
> > };
> >
> > It would be kept in rbtree like you do with quota_id but it will be also
> > used as ultimate "persistent" storage of quota information when dquot gets
> > reclaimed. We don't need to store grace times or usage information because
> > if there is non-zero usage, dquot is referenced from the inode and thus
> > cannot be reclaimed.
>
> Ok, this approach will duplicate the limits, but has advantage of having
> much smaller footprint than entire dquot so in case we don't have any
> usage in dquot we can safely reclaim it if needed without loosing user
> provided limits. Probably a worthwhile trade-off.
>
> Or perhaps we can eliminate the duplicity when we store it in the tree on
> ->destroy_dquot() and free it after we load the limits into dquot on
> ->acquire_dquo().
We could but I don't think it's worth the hassle. In particular because
->release_dquot() must not fail (there's no simple way to recover from such
failure). I don't say it is impossible to overcome but just not worth the
saved memory IMHO.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
