Hi Honza!
On Wed, Jul 16, 2003 at 01:45:07AM +0200, Jan Kara wrote:
> >
> > this is the first step, and it is neither tuned for
~~~~~~~~~~~~~~~~~~~~~~~
> > performance nor the final implementation, it's just
> > a in-between step to some future quota enhancements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > like the folowing ...
> >
> > - faster and smaller quota hashes
> Actually I think we don't care too much about performance here - the
> number of dquots is rougly #active_users*#filesystems_with_quota and we
> do lookup only on open()...
hmm, actually we do the lookup in each dqget, which from
dquot_initialize (open), dquot_transfer (chown,chgrp),
and vfs_get_dqblk/vfs_set_dqblk (quota ctls) ...
but I agree that we do not care too much about performance ...
> > - not only per super_block hashes, maybe per vfsmount?
> For current quota you must have per super_block hashes. If you'd like
> to have some "directory based" one the per vfsmount makes sense.
exactly, this is one of the future quota enhancements,
I have in mind ... not exactly directory based, but more
vfsmount based ... (which includes the superblock case)
> > - not hardcoded user/group quota ...
> After a quick look I don't see any changes wrt this. What exactly do
> you mean by this?
as I wrote "first step", "future quota enhancements" ...
this hopefully will be in the next step, or the step after ...
> > - better interface for quota extensions
> >
> > please, if somebody has any quota tests, which he/she
> > is willing to do on this code, or just want to do some
> > testing with this code, do it and send me the results ...
> >
> > I'm not interested in getting this into 2.4 without
> Actually I don't think you'll be able to get some change like this to
> 2.4 but 2.6 might be possible.
at the moment, I do not care if this is for 2.4, 2.6
or 2.8 or for my personal tree ;) I just want to test
some of my ideas regarding quota improvements/extensions,
and the current design isn't flexible enough to allow it ...
> BTW: don't you need some locking on dqhash list when
> creating/destorying hashes?
I guess this is right, but I assume the kernel lock
will do nicely (any objections? if not I'll add that)
thanks for looking at it ... ;)
best,
Herbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:01:00 EST