Messages in this thread |  | | Date | Wed, 27 Sep 2000 14:56:20 +0200 | From | Jan Kara <> | Subject | Quota fixes and a few questions |
| |
Hello.
So I've been thinking about fixes in quota (and also writing some parts). I think I thought of a bit easier implementation of featureas Al suggested. So:
* i_blocks is updated by quota in DQUOT_{ALLOC|FREE}_BLOCK (as a bonus we get fix of those unpleasant ext2 preallocation vs. quota bug) * all functions updating quota are protected by kernel lock * functions dquot_{alloc|free}_{block|inode}, dquot_transfer can block but they never block between the place where they get first dquot from inode and place where everything is updated
So we can achieve this by:
* printing warning message somewhere after we update i_blocks and quota - to achieve this I will have to change functions slightly but it's IMO easier than creating helper thread for printing * we will do write without holding dquot lock - it will just copy dquot to some buffer and write that buffer. So that now we have guaranteed that when we do dqduplicate() in dquot_{alloc|free}_{block|inode} we know it doesn't block * make notify_change() call dquot_transfer() and not the other way
What do you think about it? (to the IO stuff: I still want to move IO to pagecache but with this solution there's less probability of making stupid mistakes in stable release)
I have also two questions:
Shouldn't we sync inode in ext2_notify_change() when O_SYNC is on?
I see no serialization between ext2_notify_change()'s on one inode (just kernel lock). As it currently doesn't block there's probably no problem but when DQUOT_TRANSFER() is called from ext2_notify_change() it's not true any more. So what's the right lock to serialize on (serialization is needed at least for DQUOT_TRANSFER() itself...)? Any objections against inode->i_sem?
Honza
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |