From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 22/43] CacheFiles: Add a hook to write a single page of data to an inode [ver #46] Date: Thu, 2 Apr 2009 12:55:05 -0400 Message-ID: <20090402165505.GA21859@infradead.org> References: <200904030100.05741.nickpiggin@yahoo.com.au> <200904030232.59355.nickpiggin@yahoo.com.au> <20090402163712.GA25177@infradead.org> <200904030347.21470.nickpiggin@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: David Howells , nfsv4@linux-nfs.org, linux-kernel@vger.kernel.org, Christoph Hellwig , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <200904030347.21470.nickpiggin@yahoo.com.au> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Apr 03, 2009 at 03:47:20AM +1100, Nick Piggin wrote: > Well they now are quite well filesystem defined. We no longer take > the page lock before calling them. Not saying it's perfect, but if > the backing fs is just using a known subset of ones that work > (like loop does). The page lock doesn't matter. What matters is locks protecting the io. Like the XFS iolock or cluster locks in the cluster filesystems, and you will get silent data corruption that way. I would have sworn loop was fixed by now as gfs people were seeing these issues and submitting patches, but it looks like we never sorted this out upstream. > Probably yes. But it seems like it should have more discussion IMO > (unless it has already been had and I missed it). This came up plenty of times. > I don't think "write_one_page" sounds like a particularly good new > API addition. I also thing it's not a nice one. I still haven't seen a really good explanation of why it can't just use plain ->write