Further investigation reveals that FreeBSD also seems to suffer from
this limitation.  David, how hard do you think it would be to define a new
disklabel format in which all the geometry values are 64-bit values?  I'm
thinking a new magic value could be assigned, and  NetBSD could be taught
to recognize both values, much like was done for the new partition ID.
	Also, in looking at the code for raidframe, it seems there may be some
lurking bugs with signed versus unsigned numbers being used in the same
place.  At least, it appears there are some issues there with raidframe.
	Thoughts?
-Brian
On Apr 24,  9:15pm, David Laight wrote:
} Subject: Re: Large disk support in NetBSD, is it hard to do and is anyone 
} On Mon, Apr 24, 2006 at 12:03:28AM -0400, Thor Lancelot Simon wrote:
} > 
} > Can you use the raw partition of the disk?  The disklabel should then be
} > ignored, so should not be an issue.
} 
} Der Mouse tried that (can't remember exactly how) but then found
} massive corruption problems with both FFSv1 and FFSv2.
} 
} I don't think anyone with the time + knowledge + hardware [1] has tried
} to locate the fault.
} 
} 	David
} 
} [1] I suspect it is possible to isolate the bug using qemu to get a large
} filesystem (with few inodes) into a sparse file, then use up all the inodes
} so that a high-numbered inode can be used - for which I believe the code
} will allocate data blocks from the corresponding cylinder group.
} Unfortunately there is no way to dump the non-sparse parts of a sparse file.
} 
} Alternatively something that transferred block read/write requests to 
} userspace could be used - but I don't think that exists.
} 
} -- 
} David Laight: david@l8s.co.uk
>-- End of excerpt from David Laight