Date: Thu, 14 Nov 2002 21:39:46 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: julian@elischer.org Cc: jkh@FreeBSD.ORG, re@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: patches for sysinstall (4.x) for >1TB disks Message-ID: <20021114.213946.45875394.imp@bsdimp.com> In-Reply-To: <Pine.BSF.4.21.0211141242130.36211-200000@InterJet.elischer.org> References: <Pine.BSF.4.21.0211141242130.36211-200000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.BSF.4.21.0211141242130.36211-200000@InterJet.elischer.org>
Julian Elischer <julian@elischer.org> writes:
: If I get no complaints I'll commit these to 4.x.
: It's all different in 5.x so an MFC doesn't really work..
Is there any reason that you didn't just jump to int64_t for blocks
and such? You have a limit of 2T still with these patchs. I don't
know if the drivers would support more than this, but it wouldn't hurt
to have the upper layers know how to do it once there's driver
support... In current daddr_t is __int64_t, but only int32_t in
-stable. Of course, -stable can't support more than 2T, so maybe this
is moot.
Ideally, you'd make sure that you can do this on -current with the
massively different code, and suggest patches if not.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021114.213946.45875394.imp>
