Messages in this thread | | | From | Anton Altaparmakov <> | Subject | Re: [PATCH resend] introduce I_SYNC | Date | Fri, 1 Jun 2007 09:59:17 +0100 |
| |
Hi,
On 16 May 2007, at 18:01, Jörn Engel wrote: > Patches fixes a deadlock problem well enough for LogFS to survive. > The > problem itself is generic and seems to be ancient. Shaggy has code in > JFS from about 2.4.20 that seems to work around the deadlock. Dave > Chinner indicated that this could cause latency problems (not a > deadlock) on the NFS server side.
I agree that your patch is a good idea. I reviewed the latest incarnation and it makes sense to me. And your comment concerning the flags is a very welcome addition. Probably ought to find its way into Documentation/filesystems/Locking or vfs.txt or somewhere like that also.
Note that once your patch is applied I think it would make sense to follow up with a second patch to remove the I_LOCK flag completely. The only remaining uses are either together with I_NEW in which case I_LOCK can be removed altogether or can be substituted with I_NEW when only I_LOCK is used. This is because no places remain where we set I_LOCK by itself any more with your patch. The only place where we set it is the place where a new inode gets created in memory and in that place we also set I_NEW at the same time as I_LOCK. wait_on_inode() can then be changed to wait on I_NEW instead of on I_LOCKED. That way we have one less confusing flag to worry about and things are much easier to understand.
> I still suspect that NTFS has hit the same deadlock and its current > "fix" will cause data corruption instead.
The NTFS "fix" will not cause data corruption at all. The usage in NTFS is very different... I am afraid your patch does not address the deadlock with NTFS or rather it only addresses the inode write deadlock and does not address the get_new_inode() deadlock that exists with ilookup5() and is avoided by ilookup5_nowait(). This deadlock is inherent to what NTFS does so you don't need to worry about it. (If you want I am happy to explain it but I would rather not waste my time explaining if no-one except me cares about it...)
Best regards,
Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |