Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753138Ab1BWXrz (ORCPT ); Wed, 23 Feb 2011 18:47:55 -0500 Received: from ipmail07.adl2.internode.on.net ([150.101.137.131]:36131 "EHLO ipmail07.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751173Ab1BWXrx (ORCPT ); Wed, 23 Feb 2011 18:47:53 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK8oZU15LFEb/2dsb2JhbACmHnS8JA2FUQQ Date: Thu, 24 Feb 2011 10:47:50 +1100 From: Dave Chinner To: "Martin K. Petersen" Cc: "Darrick J. Wong" , Andreas Dilger , Jens Axboe , linux-kernel , "linux-fsdevel@vger.kernel.org" , Mingming Cao , linux-scsi Subject: Re: [RFC] block integrity: Fix write after checksum calculation problem Message-ID: <20110223234750.GM3166@dastard> References: <20110222020022.GH32261@tux1.beaverton.ibm.com> <180713DB-114C-454B-A91E-063AB0116251@dilger.ca> <20110222194538.GU27190@tux1.beaverton.ibm.com> <20110222225351.GG3166@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1679 Lines: 41 On Wed, Feb 23, 2011 at 11:24:50AM -0500, Martin K. Petersen wrote: > >>>>> "Dave" == Dave Chinner writes: > > >> Agreed. I too am curious to study which circumstances favor copying > >> vs blocking. > > Dave> IMO blocking is generally preferable in high throughput threaded > Dave> workloads as there is always another thread that can do useful > Dave> work while we wait for IO to complete. Most use cases for DIF > Dave> center around high throughput environments.... > > Yeah. > > A while back I did a bunch of tests with a liberal amount of > wait_on_page_writeback() calls added to (I think) ext2, ext3, and > XFS. For my regular workloads there was no measurable change (kernel > builds, random database and I/O tests). I'm sure we'll unearth some apps > that will suffer when DI is on but so far I'm not too worried about > blocking in the data path. > > My main concern is wrt. metadata because that's where extN really > hurts. Simple test: Unpack a kernel tarball and watch the directory > block fireworks. Given how frequently those buffers get hit I'm sure > blocking would cause performance to tank completely. I looked into > fixing this in ext2 but I had to stop because my eyes were bleeding. Not problems with metadata modifications for XFS - all metadata IO is done with a lock held preventing modifications while IO is in progress. Cheers, Dave. -- Dave Chinner david@fromorbit.com -- 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/