--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 04, 2006 at 11:37:02AM -0700, Brian Buhrow wrote:
> 	In April I started a thread on this list with the subject:
> Large disk support ...
>=20
> The take aways from that are as follows:
>=20
> 1.  Disk labels in NetBSD and FreeBSD do not support logical disks larger
> than 2^32 sectors, which is just over 2TB with 512 byte sectors.

Yep.

> 2.  If you run a filesystem on a raid 5 system using the raw partition, y=
ou
> might or might not be able to get more  space, but if you do that, you
> won't be able to do things like recalculate parity while the filesystem is
> mounted.   Given the time it takes to calculate parity on something that
> large, this is probably a trade off you're not going to want to make.  At
> least, I wasn't willing to make it.

Huh? How does the partition type being used impact the RAID system's=20
ability (or inability) to calculate parity?

Yes, parity on a multi-TB volume is a big (and irritating) deal. But I=20
don't see how partitioning or the lack there of will impact it.

> 3.  The answer is that global partitioning should be implemented, with
> wedges and legacy disklabels installed on top of the global partitions.
> This work is not done under NetBSD or FreeBSD, but some of it is done, an=
d it
> needs to be pulled together and integrated into the system.

Actually, while we have poor documentation of it, we mostly have wedges=20
and GPT working. The one issue that's realy lacking is a way to ask about=
=20
information for one partition.

That and some facility to replace our attempts to have the kernel write=20
disklabels. For instance, when programs write a file system, they take=20
steps to make sure it is recorded as having the right file system type. I=
=20
think we should keep that, and we just have to figure out how to do it.

> 4.  I looked, but couldn't be sure, and thought there might be some sign
> bit issues related to some of the code in raidframe with respect to its
> manufacturing of fictitious disklabels.  I don't know if those issues
> extend into the raidframe mechanism itself.
>=20
> 	The fact that this issue is coming up more and more often, probably
> means some work needs to be undertaken to allow NetBSD to play with these
> new larger storage facilities.

Agreed.

Take care,

Bill

--PmA2V3Z32TCmWXqI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFE2AwJWz+3JHUci9cRAtnEAKCTvCvxRJmh+LD1egIGi/CJzZG4QQCfZQni
pnDHAZjqkjzYKM+7zN+nHes=
=Awmi
-----END PGP SIGNATURE-----

--PmA2V3Z32TCmWXqI--