Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932125AbaAWIgF (ORCPT ); Thu, 23 Jan 2014 03:36:05 -0500 Received: from ipmail04.adl6.internode.on.net ([150.101.137.141]:45352 "EHLO ipmail04.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750831AbaAWIgD (ORCPT ); Thu, 23 Jan 2014 03:36:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAIAAbU4FJ5LKVw/2dsb2JhbABbgwyDOrN2hVCBDhd0giUBAQEEOhwjEAgDDgoJJQ8FJQMhE4gExRUXFo4dSQeEOASYIZIZgW+BUiiBLQ Date: Thu, 23 Jan 2014 19:35:58 +1100 From: Dave Chinner To: Andrew Morton Cc: James Bottomley , "linux-scsi@vger.kernel.org" , "linux-ide@vger.kernel.org" , Chris Mason , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "mgorman@suse.de" , "linux-fsdevel@vger.kernel.org" , "lsf-pc@lists.linux-foundation.org" , Ric Wheeler Subject: Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes Message-ID: <20140123083558.GQ13997@dastard> References: <20140122151913.GY4963@suse.de> <1390410233.1198.7.camel@ret.masoncoding.com> <1390411300.2372.33.camel@dabdike.int.hansenpartnership.com> <1390413819.1198.20.camel@ret.masoncoding.com> <1390414439.2372.53.camel@dabdike.int.hansenpartnership.com> <52E00B28.3060609@redhat.com> <1390415703.2372.62.camel@dabdike.int.hansenpartnership.com> <52E0106B.5010604@redhat.com> <1390419019.2372.89.camel@dabdike.int.hansenpartnership.com> <20140122115002.bb5d01dee836b567a7aad157@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140122115002.bb5d01dee836b567a7aad157@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 22, 2014 at 11:50:02AM -0800, Andrew Morton wrote: > On Wed, 22 Jan 2014 11:30:19 -0800 James Bottomley wrote: > > > But this, I think, is the fundamental point for debate. If we can pull > > alignment and other tricks to solve 99% of the problem is there a need > > for radical VM surgery? Is there anything coming down the pipe in the > > future that may move the devices ahead of the tricks? > > I expect it would be relatively simple to get large blocksizes working > on powerpc with 64k PAGE_SIZE. So before diving in and doing huge > amounts of work, perhaps someone can do a proof-of-concept on powerpc > (or ia64) with 64k blocksize. Reality check: 64k block sizes on 64k page Linux machines has been used in production on XFS for at least 10 years. It's exactly the same case as 4k block size on 4k page size - one page, one buffer head, one filesystem block. 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/