Hi,
On Wed, May 23, 2001 at 05:40:44AM -0400, Alexander Viro wrote:
> On Wed, 23 May 2001, Stephen C. Tweedie wrote:
> > I don't see how you can avoid it. What about something like a "chown"
> > to a previously-unused uid? We have 32-bit uids now, remember, so
> > unless you preallocate a very large quota file we're going to have to
> > deal with allocating the entry *somewhere*.
>
> <shrug> Code in the current tree depends on that.
> Anyway, correct way to deal with that is pretty simple - take quota
> allocation/freeing out of lock_super(). BTDT. See patchset on
> ftp.math.psu.edu/pub/viro/ext2.tar.gz - ialloc and balloc parts.
Yep. There are really only two ways out of this: abandon the assumption
that quota ops can't recurse, or prevent them from recursing. The
former can be done with the superblock lock fixes for allocation.
The latter is possible if we populate the quota file entries in
advance. Here, that probably implies doing the population inside
ext2_read_inode() while we init the dquot, so that any subsequent
quota ops on the inode are guaranteed not to require allocation
(except for chown, which is OK because we don't get recursive calls
into chown very often!).
There's also this recursion:
write(user)->write_dquot(user)->write(quotafile)->write_dquot(root)
which also goes away if we preallocate quotas on init_dquot/chown. If
that recursion ever proves to be a problem, we may just have to do the
preallocation.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
