Subject: Re: newfs can't make filesystems over 1TB in size
To: Brian Buhrow <buhrow@lothlorien.nfbcal.org>
From: Bill Studenmund <wrstuden@netbsd.org>
List: current-users
Date: 12/10/2002 10:35:31
On Mon, 9 Dec 2002, Brian Buhrow wrote:

> On Dec 9,  8:18pm, Bill Studenmund wrote:
> } Subject: Re: newfs can't make filesystems over 1TB in size
> } Uhm, why not change them all to off_t? Even though you're not changing
> } size, you're changing semantics, and so you'd have to supply compatability
> } calls for everything (where the values make it to userland), so why not
> } just fix things once & for all?
>
> 	Hi bill.  Are you suggesting that I should consider
> changing the on-disk format of disklabel such that the size of a partition

Sorry, I thought you were talking more about internal driver issues, and
kernel/userland ones. No, changing the on-disk format is a bit more than I
had in mind (though we do need to do it too).

> is represented by an off_t, a 64-bit signed value?  Do you think this might
> be overkill since NetBSD seems to already address physical disk sectors as
> unsigned 32-bit valuse, a state of affairs which will currently let us talk
> to a 4-TB disk?  I was merely thinking that the disk drivers and

Note: 2^32 512-byte sectors = 2 TiB, not 4.

Let's see. When I was at Fry's last week, they had 100 GB disks (might
have had bigger, I didn't look). 40-disk arrays are available (and have
been for quite some time). 40 * 100 GB == 4000 GB which is much more than
2 TiB.

We need to start fixing this.

> disklabel(8) program ought to reflect that reality and print out meaningful
> data.  Is there a semantic I'm missing, and unintentionally changing?

Old programs that use the old get-disklabel calls (and anything else that
gets disk stats) will get confused if we pass a large unsigned number
where they expect a signed number. Do you really want something thinking
you have -2199002819855 blocks on a disk? :-)

> Changing the on-disk format seems like quite a significant one, and
> something to be worked toward, whereas I was mostly suggesting a cosmetic
> change, initially, at least, which would improve the usability of NetBSD.

But it's not just cosmetic for older programs. :-)

Take care,

Bill