Subject: Re: newfs can't make filesystems over 1TB in size
To: Brian Buhrow <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
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
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. :-)