From owner-freebsd-fs@FreeBSD.ORG  Fri Jun 11 18:14:49 2004
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BDBFB16A4CE
	for <fs@freebsd.org>; Fri, 11 Jun 2004 18:14:49 +0000 (GMT)
Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 15D6D43D31
	for <fs@freebsd.org>; Fri, 11 Jun 2004 18:14:49 +0000 (GMT)
	(envelope-from bde@zeta.org.au)
Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au
	[61.8.0.86])i5BIEj5v032655;	Sat, 12 Jun 2004 04:14:45 +1000
Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246])
	i5BIEg2O022504;	Sat, 12 Jun 2004 04:14:44 +1000
Date: Sat, 12 Jun 2004 04:14:42 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Brian Bergstrand <brian@classicalguitar.net>
In-Reply-To: <D517B455-BBC4-11D8-8C2A-0003930A674E@classicalguitar.net>
Message-ID: <20040612035325.D15028@gamplex.bde.org>
References: <D517B455-BBC4-11D8-8C2A-0003930A674E@classicalguitar.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: fs@freebsd.org
Subject: Re: Ext2 vs UFS getlbns
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2004 18:14:49 -0000

On Fri, 11 Jun 2004, Brian Bergstrand wrote:

> I just noticed something in ext2_getlbns() (ext2_bmap.c, v1.57) vs.
> ufs_getlbns() (ufs_bmap.c, v1.60)
>
> In the last loop to setup the indir array,
>
> UFS does:
>
> {
> ...
> blockcnt /= MNINDIR(ump);
> off = (bn / blockcnt) % MNINDIR(ump);
>
> ++numlevels;
> ap->in_lbn = metalbn;
> ap->in_off = off;
> ap->in_exists = 0;
> ++ap;
>
> metalbn -= -1 + off * blockcnt;
> }
>
> While Ext2 does:
>
> {
> ...
> off = (bn / blockcnt) % MNINDIR(ump);
>
> ++numlevels;
> ap->in_lbn = metalbn;
> ap->in_off = off;
> ap->in_exists = 0;
> ++ap;
>
> metalbn -= -1 + off * blockcnt;
> blockcnt /= MNINDIR(ump);
> }
>
> Notice that blockcnt is changed AFTER offset/metalbn in Ext2 and BEFORE
> those in UFS.
>
> Was this change in Ext2 done on purpose for some reason? It makes a
> difference in calculating in_off and metalbn for some block #'s.

This is to fix overflow in the calculation of block numbers for triple
indirect blocks.  ffs used to do this, and ext2_getlbns() was a copy
ufs_getlbns(), but ffs was changed back to use simpler code when its
daddr type (ufs2_daddr_t) was changed to 64 bits and the longs in
ufs_getlbns() were fixed to use ufs_daddr_t.  Overflow is probably
theoretically possible again, but it would take a 128-bit calculation
to avoid it and 64 bit block numbers should be enough for anyone.

This difference shouldn't affect in_off or metalbn for any reachable
block number (32 bit ones in ext2fs).  There is another variable
"int64_t qblockcnt" that is used instead of "long blockcnt" in
some places in ext2_getlbns().  The logic for using blockcnt in the
above is a little different because earlier calculations set
qblockcnt instead of qblockcnt.

Bruce