From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: hole-punch vs fault Date: Fri, 29 Nov 2013 06:11:55 -0700 Message-ID: <20131129131154.GA11106@parisc-linux.org> References: <20131127134831.GI24288@parisc-linux.org> <20131127221932.GA27330@quack.suse.cz> <20131128023343.GJ24288@parisc-linux.org> <20131128044454.GL24288@parisc-linux.org> <20131128221246.GQ8803@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:49221 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752297Ab3K2NL5 (ORCPT ); Fri, 29 Nov 2013 08:11:57 -0500 Content-Disposition: inline In-Reply-To: <20131128221246.GQ8803@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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."