Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754711Ab1EPTby (ORCPT ); Mon, 16 May 2011 15:31:54 -0400 Received: from mail.parknet.co.jp ([210.171.160.6]:54059 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668Ab1EPTbw (ORCPT ); Mon, 16 May 2011 15:31:52 -0400 From: OGAWA Hirofumi To: djwong@us.ibm.com Cc: Jan Kara , Theodore Tso , Alexander Viro , Jens Axboe , "Martin K. Petersen" , Jeff Layton , Dave Chinner , linux-kernel , Dave Hansen , Christoph Hellwig , linux-mm@kvack.org, Chris Mason , Joel Becker , linux-scsi , linux-fsdevel , linux-ext4@vger.kernel.org, Mingming Cao Subject: Re: [PATCHSET v3.1 0/7] data integrity: Stabilize pages during writeback for various fses References: <87tyd31fkc.fsf@devron.myhome.or.jp> <20110510123819.GB4402@quack.suse.cz> <87hb924s2x.fsf@devron.myhome.or.jp> <20110510132953.GE4402@quack.suse.cz> <878vue4qjb.fsf@devron.myhome.or.jp> <87zkmu3b2i.fsf@devron.myhome.or.jp> <20110510145421.GJ4402@quack.suse.cz> <87zkmupmaq.fsf@devron.myhome.or.jp> <20110510162237.GM4402@quack.suse.cz> <87vcxipljj.fsf@devron.myhome.or.jp> <20110516184736.GL20579@tux1.beaverton.ibm.com> Date: Tue, 17 May 2011 04:31:37 +0900 In-Reply-To: <20110516184736.GL20579@tux1.beaverton.ibm.com> (Darrick J. Wong's message of "Mon, 16 May 2011 11:47:36 -0700") Message-ID: <87oc3230iu.fsf@devron.myhome.or.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2485 Lines: 49 "Darrick J. Wong" writes: >> OK. E.g. usual workload on desktop, but FS like ext2/fat. > > In the frequent rewrite case, here's what you get: > > Regular disk: (possibly garbage) write, followed by a second write to make the > disk reflect memory contents. > > RAID w/ shadow pages: two writes, both consistent. Higher memory consumption. > > T10 DIF disk: disk error any time the CPU modifies a page that the disk > controller is DMA'ing out of memory. I suppose one could simply retry the > operation if the page is dirty, but supposing memory writes are happening fast > enough that the retries also produce disk errors, _nothing_ ever gets written. > > With the new stable-page-writes patchset, the garbage write/disk error symptoms > go away since the processes block instead of creating this window where it's > not clear whether the disk's copy of the data is consistent. I could turn the > wait_on_page_writeback calls into some sort of page migration if the > performance turns out to be terrible, though I'm still working on quantifying > the impact. Some people pointed out that sqlite tends to write the same blocks > frequently, though I wonder if sqlite actually tries to write memory pages > while syncing them? > > One use case where I could see a serious performance hit happening is the case > where some app writes a bunch of memory pages, calls sync to force the dirty > pages to disk, and /must/ resume writing those memory pages before the sync > completes. The page migration would of course help there, provided a memory > page can be found in less time than an I/O operation. > > Someone commented on the LWN article about this topic, claiming that he had a > program that couldn't afford to block on writes to mlock()'d memory. I'm not > sure how to fix that program, because if memory writes never coordinate with > disk writes and the other threads are always writing memory, I wonder how the > copy on disk isn't always indeterminate. I'm not thinking data page is special operation for doing this (at least logically). In other word, if you are talking about only data page, you shouldn't send patches for metadata with it. Thanks. -- OGAWA Hirofumi -- 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/