From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Zippel Subject: Re: [PATCH 2/9] sector_t format string Date: Thu, 10 Aug 2006 14:24:13 +0200 (CEST) Message-ID: References: <1155172843.3161.81.camel@localhost.localdomain> <20060809234019.c8a730e3.akpm@osdl.org> <44DB203A.6050901@garzik.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 scrub.xs4all.nl ([194.109.195.176]:24974 "EHLO scrub.xs4all.nl") by vger.kernel.org with ESMTP id S1161219AbWHJMaA (ORCPT ); Thu, 10 Aug 2006 08:30:00 -0400 To: Jeff Garzik In-Reply-To: <44DB203A.6050901@garzik.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, On Thu, 10 Aug 2006, Jeff Garzik wrote: > > On Wed, 9 Aug 2006, Andrew Morton wrote: > > > > > That also being said... does a 32-bit sector_t make any sense on a > > > 48-bit-blocknumber filesystem? I'd have thought that we'd just make ext4 > > > depend on 64-bit sector_t and be done with it. > > > > Is this really necessary? There are a few features, which would make ext4 > > also interesting at the low end (e.g. extents). Storing 64bit values on disk > > is fine, but they should be converted to native values as soon as possible. > > Consider what that means. "converted to native" means dealing with truncation > issues... Yes, it does, but I don't think it's that difficult - basically returning -EIO, it should be part of the basic error handling. Afterwards you don't have to waste cpu/memory on unused data anymore. bye, Roman