Date: Mon, 3 Apr 95 10:35:13 MDT From: terry@cs.weber.edu (Terry Lambert) To: davidg@Root.COM Cc: hackers@FreeBSD.org, bde@zeta.org.au Subject: Re: 4 gig st15150n disk setups Message-ID: <9504031635.AA06845@cs.weber.edu> In-Reply-To: <199504020257.SAA00332@corbin.Root.COM> from "David Greenman" at Apr 1, 95 06:57:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >>I was under the impression that these were atomic block offsets -- NOT > >>byte offsets. > > I'm not sure if I see the distinction you're trying to make. The problem is > that there are places in the kernel that convert from a block offset to a 32 > bit byte offset (and back again in some cases). This isn't intentional - it's > simply a matter of the wrong type being used in some cases. The obvious result > is a loss of precision. The end result is usually sign extension from the > 32bit signed type to the 64bit signed type and thus leads to negative block > offsets. OK -- that's all I needed. I was under the impression that the ONLY problems lay in sign extension and manifest constants; the loss of precision mans that there are two bad windows (one at both the 2G and the 1T mark instead of just one or the other). I wonder what the theoretical and measured savins are for indirecting blocks this way; I suppose the theory is that it saves a fault to get to the indirect block; yet at the same time it introduces indirection for what would normally be the direct blocks at the front of the file. It seems that the savings would depend on access patterns, and would complicate greatly files with early holes. Maybe we should consider if the change is worth the extra complication? Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504031635.AA06845>