Bill Studenmund wrote:

> Actually it's not a problem in ffs. ffs uses ufs_daddr_t's which are, as I
> understand it, addresses of FFS blocks. i.e. on an 8k/1k system, they are
> addresses of the 8k chunks. Thus with signed ufs_daddr_t you can have
> 2^31*8k worth of fs, or ~16 TB. Not enough? grow the disk blocks. 16k
> blocks will give 32 TB, 32k -> 64 TB, and 64k -> 128 TB.

Although they are the addresses of the 8k chunks, the addresses
themselves are the addresses of 1KB chunks on the disc. Ie the data in
the block lists will look something like (for a contiguous file on an
8KB/1KB FS):
	64
	72
	80
apart from the last block, which will not be a multiple of 8 in the case
of a fragment. So actually, your disk size will still be limited by the
number of fragments fitting into that 32 bit word, not blocks... No?

> A bigger, more immediate, problem is that daddr_t is an int32_t. :-)

Referencing indirect blocks as negative numbers seemed a pretty ugly
hack. Maybe a better abstraction is needed.

	Neil