From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [PATCH 2/9] sector_t format string Date: Thu, 10 Aug 2006 09:14:57 -0400 Message-ID: <44DB3151.8050904@garzik.org> References: <1155172843.3161.81.camel@localhost.localdomain> <20060809234019.c8a730e3.akpm@osdl.org> <44DB203A.6050901@garzik.org> <44DB25C1.1020807@garzik.org> <44DB27A3.1040606@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Morton , cmm@us.ibm.com, linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Return-path: Received: from srv5.dvmed.net ([207.36.208.214]:16608 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S1161883AbWHJNPE (ORCPT ); Thu, 10 Aug 2006 09:15:04 -0400 To: Roman Zippel In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Roman Zippel wrote: > On Thu, 10 Aug 2006, Jeff Garzik wrote: >>>> Or you could just not bother, and leave everything as u64. >>> Why? >> To eliminate needless complexity and keep things simple and obvious? > > Considering the amount of complexity we add for the high end, why is it > suddenly a bad thing to add even a _little_ complexity for the other end? This is ext4 not ext3 we're talking about. The next gen Linux filesystem should be tuned for modern machines -- 64bit, moving forward -- while still working just fine on 32bit. Jeff