Date: Sat, 12 Jun 2004 04:14:42 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Brian Bergstrand <brian@classicalguitar.net> Cc: fs@freebsd.org Subject: Re: Ext2 vs UFS getlbns Message-ID: <20040612035325.D15028@gamplex.bde.org> In-Reply-To: <D517B455-BBC4-11D8-8C2A-0003930A674E@classicalguitar.net> References: <D517B455-BBC4-11D8-8C2A-0003930A674E@classicalguitar.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040612035325.D15028>