From owner-freebsd-hackers Fri Nov 15 0:35:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 745A237B401; Fri, 15 Nov 2002 00:35:11 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 078ED43E6E; Fri, 15 Nov 2002 00:35:11 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by attbi.com (rwcrmhc53) with ESMTP id <20021115083503053005vmete>; Fri, 15 Nov 2002 08:35:04 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA41010; Fri, 15 Nov 2002 00:34:05 -0800 (PST) Date: Fri, 15 Nov 2002 00:34:04 -0800 (PST) From: Julian Elischer To: "M. Warner Losh" Cc: jkh@FreeBSD.ORG, re@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: patches for sysinstall (4.x) for >1TB disks In-Reply-To: <20021114.213946.45875394.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It turns out that these patches almost apply in -current but while they are enough to allow 4.x to work, they are not sufficient to allow -current to work. there is a bunch of different code in -current that is just not there in 4.x and Geom is sticking its finger in the picture as well. I'd rather just get 4.x capable of handling a 2 TB drive and handle -current as a separate issue. 4.x will never need a partition > 1TB and will never handle a drive > 2TB without a LOT of work. but -current might. S it's not really worth making 4.x sysinit capable of doing it. These patches are sufficient for what we can do in 4.x, On Thu, 14 Nov 2002, M. Warner Losh wrote: > In message: > Julian Elischer 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message