[lkml]   [2000]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectQuota fixes and a few questions

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
* 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

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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.039 / U:26.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site