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 13:05:21 +0200 (CEST) Message-ID: References: <1155172843.3161.81.camel@localhost.localdomain> <20060809234019.c8a730e3.akpm@osdl.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: 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]:4750 "EHLO scrub.xs4all.nl") by vger.kernel.org with ESMTP id S1161166AbWHJLLD (ORCPT ); Thu, 10 Aug 2006 07:11:03 -0400 To: Andrew Morton In-Reply-To: <20060809234019.c8a730e3.akpm@osdl.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Hi, 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. bye, Roman