Ok, so we need to attack this problem. The areas that need change can
roughly be split in 3 parts, all relating to using 32-bit fields in
structures:


	1) Disklabels. They use 32bit values.
	   Solution:
		implement wedges. It would be a waste to go for a
	   	disklabel with 64-bit fields, since people agree that disklabels
	   	should be phased out anyway.
	   	So let's do it. For the original discussion (to save some
	   	web archive searching), see

	   	http://www.science.uva.nl/~frank/wedge.txt

	   	(website at my old job, it happened almost 3 years ago now).
		I'm not even suggesting that there is a discussion about
		whether this method is good or not -- it's generally
		agreed that it is. An open issue is booting. Bootblocks
		must find the filesystem and load the kernel, and the
		kernel must find it's root filesystem. This may be
		platform dependent. I want a list of platforms and how
		we address this issue for this platform.

	2) On-disk datastructures. Current filesystems use 32 bits in
	   a lot of places.
	   Solution:
		Identify all structures in filesystems that
		are 'native' to NetBSD using 32 bits where they
		should be using 64. For FFS, this has already been
		done in UFS2, so that code should be used. For LFS,
		we must look at it ourselves (though it shares
		many FFS datastructures).

		What we need, initially, is a list of structures to
		change, and what is needed to bring in UFS2. Or at
		least the parts that deal with larger offsets (e.g.
		we should at least be on-disk compatible with it).

	3) In-core datastructures. The main offender is daddr_t,
	   which should be bumped to 64 bits. The other ones are
	   probably in the FS-specific structures. Find them and
	   identify issues with them. Check prior art as well
	   (i.e. UFS2).

Now as usual in a volunteer project, the issue is: who is going
to do this. I know that my plate is pretty full, but I can
coordinate this (and be a responsible Core member for a change..).

I suggest following up on the above issues, make a list of things
to do, and start a CVS branch.

- Frank

-- 
Frank van der Linden                                    fvdl@wasabisystems.com
==============================================================================
Quality NetBSD Development, Support & Service.   http://www.wasabisystems.com/