On Fri, Nov 29, 2013 at 09:12:46AM +1100, Dave Chinner wrote: > Indeed, we've already discussed this at length - if we are going to > introduce a new method of synchronisation between mmap and > holepunch, then we cannot ignore all the other mmap vs IO > synchronisation problems we have that are caused by the same issue. > Hacking workarounds into the holepunch/mmap paths is not a robust or > maintainable solution. This isn't hacking in a workaround. This is a solution to the problem that assumes holepunches are rare, and it's OK to make the fault path retry if a holepunch happened. I agree it needs to be documented and the exact details of what is protected by i_damaged_mutex needs to be clear. > a) it is a entire file lock and truncate/holepunch do not > affect the entire scope of the file. i.e. there is no > reason why holepunch cannot run concurrently with IO if > they are to different ranges of a file. Yes, if we care about the scalability of truncate and holepunch. I really don't think that's an important workload. > b) it increases the struct inode by at least 5%. If we are > going to increase the inode by that much, we better make > sure we solve more than one isolated, relatively rare > corner case behaviour. About 7% (568 -> 608 bytes) with my .config (SMP, SPIN_ON_OWNER, !DEBUG_MUTEXES, !DEBUG_LOCK_ALLOC). I rearranged the order (thanks, pahole!) to put i_damage in the hole created by private_lock. I'm solving two cases here, one is holepunch vs fault for regular files. The other is truncate vs fault for XIP files, which is probably a little less rare. I think the same mechanism can be used when a filesystem is doing a defragment or otherwise moving blocks around on an XIP block device. Look, I'm not attached to the i_damage solution, but I do need something to protect against truncate vs fault on XIP. Fixing holepunch vs fault too just felt like the right thing to do. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
