I've tested doing a sync every 1 soecond (using watch -n 1 sync) while doing a commit on a VM where the REDO file was over 200M.
No Crash nor Hangs, therefore seem to be much better.
I'll keep you inform if I have the problem again, otherwise it's fine.
Thanks a lot and keep up the good works guys.
PS: Similar problems on NT would have taken months to get a fix!!!
Cheers
Andre
On Sat, 24 April 1999, Jan Kara wrote:
>
> Hello.
>
>
>
> So I hopefully fixed the sync problem. The problem was that when we were
>
> writing dquot it was locked. So when ext2 needed to grow file (fill in hole)
>
> it wanted to update dquot and so waited for lock.. forever. The thing I
>
> don't understand is how this could happen so often so there is possibility
>
> I missed some other problem which also causes deadlock. Please test.
>
> I've also done some other minor fixes and I know about one bad problem -
>
> when we do quota_off we clear the pointers to dquots only from inodes
>
> attached to some filp. But there might be some inodes with dquots also
>
> in inode cache. Then they will point to invalidated dquots and it is not
>
> good - for these inodes the quota will not take any effect when
>
> again turned on for example. The solution would be to go through inodes
>
> in i-cache and not just through filps but this needs to "export" lists
>
> from inode.c. Is there any reason why I shouldn't do it?
>
>
>
> I also have one question:
>
> What is the effect of dquot_updating entries in dqget? I think there is
>
> no need for them.
>
>
>
> Honza.
>
>
Andre Couture
PCDOCS/Fulcrum S.A. - Europe
Office: +33(1)46.29.07.40
GSM Europe: +33(6)07.04.35.65
FAX/Voicemail Europe: +33(1) 53.01.29.63
FAX/Voicemail Canada: +1(514) 221-2261
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/