Jan Kara wrote:
>
> Hello,
>
> after some discussion with Andrew Morton I decided to write a few
> rules about what quota expects from filesystem and what filesystem
> should expect from quota. Does anybody have any comment?
>
> Honza
>
> Current state in Alan's kernels
> ===============================
>
> Required locks:
> Quota itself does require only BKL. This lock is locked in DQUOT_ macros
> from quotaops.h so callers of these macros doesn't need to lock anything.
>
> Blocking:
> Any quota call can schedule.
>
> Reentrancy:
> Any quota call require any IO (read/write (including block allocation))
> on quotafile from filesystem.
Block allocation is a problem. Both ext3 and ext2 hold lock_super()
while running DQUOT_ALLOC_BLOCK() and DQUOT_FREE_BLOCK(). If those
functions want to allocate new blocks against the same fs, we'll
deadlock.
An easy fix is to move these quota calls outside lock_super().
> Quota calls DQUOT_ALLOC/PREALLOC_SPACE/BLOCK can update some fields
> in inode (currently i_blocks, i_bytes) and call mark_inode_dirty() on
> passed inode.
>
> Planned state
> =============
>
> Required locks:
> Nothing substantial changes. Just BKL might be substituted by some quota-
> specific spinlock.
>
> Blocking:
> No change - any quota call can schedule.
>
> Reentrancy:
> DQUOT_INITIALIZE(), DQUOT_TRANSFER() require any IO (read/write
> (including block allocation)).
> DQUOT_DROP() require write (write without allocation is must, I'd rather
> have also read & allocation possible for future so assume it's also required).
> DQUOT_ALLOC/PREALLOC_BLOCK/SPACE/INODE() don't require any IO (but see below)
OK, if dquot_initialize() can make sure that any required disk
blocks are instantiated then we don't have a lock_super() deadlock
any more.
I had a bit of a fiddle, but was not able to easily force the
quota code to grow the size of the quota file. Can you please
suggest a set of steps which will cause the quota file to grow?
We need to decide how to proceed with this. Should ext[23]
do something to avoid the lock_super() problem, or should they
wait for the dquot_initialize() changes?
> Thing which is left is that mark_inode_dirty() (which can result in
> foo_dirty_inode()). Quota must update i_blocks & i_bytes fields to avoid
> races between space/inode allocation and dquot_transfer() - ie. chown, chgrp.
> Of course it needn't call mark_inode_dirty() and leave it on caller but
> I think this is not good design (I see lots of forgotten mark_inode_dirty()
> in fs code :)). Actually solution which I've thought of and also already
> implemented is making _NODIRTY version of those DQUOT_ALLOC... macros
> which don't call mark_inode_dirty() (this is left on filesystem). Does
> anybody have any better solution (I don't like this one much but I didn't find
> better)?
The current mark_inode_dirty() call from DQUOT_*() is not a problem
for ext3.
Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
