Hello,
> Alexander Viro wrote:
> >
> >
> > Stop here. You have a hole in quota file. You are not supposed to.
>
> I think it's a misfit between Linus' kernel and the
> quota tools from http://sourceforge.net/projects/linuxquota/
>
> Running `quotacheck' creates an aquota.user which is
> only ~7200 bytes in size. But the quota code in Linus' kernel
> tries to write quota info into this file at offset
>
> inode->i_uid * sizeof(struct dqblk)
>
> So Linus' quotafile is just a flat array. With my
> UID of 34202, ->i_size grew to over a meg. It's
> super-holey.
There are two quota formats:
The first in Linus's tree - it uses file quota.user and it's
simple flat file (and I agree that hole in it can cause deadlock :().
The second in Alan's tree - it uses file aquota.user and it
has more complicated file format. The deadlock you've shown can't
happen in Alan's tree because lock_dquot() was removed from write path
(it's now used only during first read).
When you want quotacheck to create files for old quota format you
can specify '-F vfsold' option.
> Now I *assume* that quotacheck should have instantiated
> the block which corresponds to 34202 in aquota.user. And
> when new users are added to the quotafile, the quota tools
> must instantiate the user's corresponding blocks, so filesystems
> aren't nastily reentered in this manner. Sounds good to me,
> anyway.
>
> But quotacheck didn't instantiate my block.
>
> Linus' tree and Alan's are showing a 2000 line diff in
> dquot.c alone. `quotaon' seems to be passing arguments into
> sys_quotactl() which it doesn't understand, etc.
? quotaon in my utils should feed the Linus's kernel with arguments
it understands (and especially it shouldn't feed it with aquota files
when not explicitely asked to). What does it write?
Honza
--
Jan Kara <[EMAIL PROTECTED]>
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
