> This behaviour comes from the fact that inodes keep lingering longer
> with the newer 2.1.xx kernels.In earlier kernels 2.0.x etc. we didn't
> have the now used dcache structs and all inodes were cleared quite soon
> after the last iput had taken place. Due to the way the new dcache stuff
> works lots of inodes keep lingering which will result in an lingering
> dquot (kernel quota structure) for each id used. The problem described
> above comes due to the fact that you cycle through all available uid/gid
> which will result in large allocations of dquots. The easiest way to get
> ride of the messages is increasing the number of concurrent dquots. You
> can increase them using the following command somewhere in your bootup:
>
> echo 4096 > /proc/sys/fs/dquot-max
>
> Maybe we should increase the default upper limit or purge the inode cache
> faster for inodes opened for writing. (This problem only occurs on inodes
> (files) which are opened for writing.)
Hi Marco,
I can suggest a couple of ways that the issue of dcache tying up dquota
could be addressed. One approach would be to move the decision to drop
quota into the file op release function, so that inodes held by dcache
but no longer in use by a file wouldn't hold dquota.
Another approach would be to have the dquota allocation routines shrink
the dcache for a particlar device if too much quota was tied up on it.
Also, on another dquota-related topic: there appear to be some serious
problems with the dquota list management that could lead to list
corruption under heavy load. Are you (or someone else) interested in
looking into this?
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/