Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752949Ab0F2CVP (ORCPT ); Mon, 28 Jun 2010 22:21:15 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:39435 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752344Ab0F2CVO convert rfc822-to-8bit (ORCPT ); Mon, 28 Jun 2010 22:21:14 -0400 MIME-Version: 1.0 In-Reply-To: <20100629015822.GD24343@mail.oracle.com> References: <20100628173529.GA10573@mail.oracle.com> <20100629002421.GY6590@dastard> <20100629005403.GC24343@mail.oracle.com> <20100629015822.GD24343@mail.oracle.com> Date: Mon, 28 Jun 2010 19:20:33 -0700 Message-ID: Subject: Re: [Ocfs2-devel] [PATCH] Revert "writeback: limit write_cache_pages integrity scanning to current EOF" From: Linus Torvalds To: Linus Torvalds , Dave Chinner , Linux Kernel , ocfs2-devel@oss.oracle.com, Tao Ma , Dave Chinner , Christoph Hellwig , Mark Fasheh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1950 Lines: 39 On Mon, Jun 28, 2010 at 6:58 PM, Joel Becker wrote: > > ? ? ? ?Well, shit. ?Something has changed in here, or we're really > really (un)lucky. ?We visited this code a year ago or so when we had > serious zeroing problems, and we tested the hell out of it. ?Now it is > broken again. ?And it sure looks like that block_write_full_page() check > has been there since before git. Hmm. I'm actually starting to worry that we should do the revert after all. Why? Locking. That page-writeback.c thing decides to limit the end to the inode size the same way that block_write_full_page() does, but block_write_full_page() holds the page lock, while page-writeback.c does not. Which means that as a race against somebody else doing a truncate(), the two things really are pretty different. That said, write_cache_pages() obviously doesn't actually invalidate the page (the way block_write_full_page() does), so locking matters a whole lot less for it. If somebody is doing a concurrent truncate or a concurrent write, then for the data to really show up reliably on disk there would obviously have to be a separate sync operation involved, so even with the lack of any locking, it should be safe. I dunno. Filesystem corruption makes me nervous. So I'm certainly totally willing to do the revert if that makes ocfs2 work again. Even if "work again" happens to be partly by mistake, and for some reason that isn't obvious. Your call, I guess. If any ocfs2 fix looks scary, and you'd prefer to have an -rc4 (in a few days - not today) with just the revert, I'm ok with that. Even if it's only a "at least no worse than 2.6.34" situation rather than a real fix. Linus -- 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/