From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tony Battersby" Subject: RE: [PATCH] [RFC] LBD fixes for Linux 2.6.10 [2/2] Date: Thu, 13 Jan 2005 15:46:04 -0500 Message-ID: <05Jan13.154605est.333580@cyborg.cybernetics.com> References: <20050113184302.GC30982@parcelfarce.linux.theplanet.co.uk> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Return-path: Received: from host02.cybernetics.com ([206.246.200.18]:25613 "EHLO cybernetics.com") by vger.kernel.org with ESMTP id S261684AbVAMU44 (ORCPT ); Thu, 13 Jan 2005 15:56:56 -0500 To: "'Matthew Wilcox'" In-Reply-To: <20050113184302.GC30982@parcelfarce.linux.theplanet.co.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > > 1) Use sector_t rather than long or unsigned long for block numbers. > > For auditing, just search for all occurrences of "long" in > the filesystem > > code and make sure it is not referring to a block number. > > That's actually not wise. For ext3, the block numbers _on disc_ > are 32-bit in size, so making them sector_t in memory is just a waste. > reiserfs seems to be the same. OTOH, XFS does use 64-bit > blocks on disc, > so should use an explicitly 64-bit size in memory too. Thanks, that's why I was looking for feedback before going further. Is there anywhere in the fs-specific code that deals with real sector numbers rather than fs block numbers? Any variable that deals with real sector numbers should be sector_t, even if the filesystem uses only 32-bit block numbers. For example, an ext3 filesystem might be created in the 3-4 TB range of a 4 TB disk, in which case the fs block numbers fit into a 32-bit quantity but the real sector numbers need to be 64-bit because of the large starting offset. If the fs-specific code doesn't deal with real sector numbers, then there is probably nothing that needs to be done for ext3 or reiserfs. Anthony J. Battersby Cybernetics