Re: [PATCH resend] introduce I_SYNC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux