lkml.org 
[lkml]   [2003]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Quota Hash Abstraction 2.4.22-pre6

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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.024 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site