From owner-freebsd-geom@FreeBSD.ORG Wed May 25 17:43:33 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883A41065670; Wed, 25 May 2011 17:43:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 24C758FC14; Wed, 25 May 2011 17:43:33 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4PHb8xJ031643 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 11:37:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DDD1C56.70706@FreeBSD.org> Date: Wed, 25 May 2011 11:37:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73D4228C-58DF-4A73-A562-34AA4BBF08C4@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDD1C56.70706@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 25 May 2011 11:37:12 -0600 (MDT) Cc: Marcel Moolenaar , freebsd-geom@FreeBSD.org, "Andrey V. Elsukov" Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:43:33 -0000 On May 25, 2011, at 9:12 AM, Andriy Gapon wrote: > on 24/05/2011 21:12 Marcel Moolenaar said the following: >> With respect to the creation: >>=20 >> Since out synthesized geometry is not necessarily the same >> as other OSes, we could opt to synthesize a geometry that >> has a track size (=3D sectors/track) that is a multiple of 8 >> (to play nice with 4K sectors), and/or take the stripe >> size of the underlying GEOM into account. This fundamentally >> doesn't change a thing for MBR, but has the side effect of >> achieving some of the goals *and* automatically works for >> EBR as well. >>=20 >> Thus: rather than hack MBR and forgetting about EBR and other >> schemes, maybe we only have to tweak the geometry synthesis >> to give people what they want without going over board.=20 >=20 > I don't think that currently we do synthesize any geometry in kernel. We do. There's at least three cases I can think of. For CAM da = devices, we always synthesize something bogus. For ata devices on pc98 = machines, we create the right fake geometry when certain conditions = require us to create a fake geometry. CAM on pc98 machines also does = this. The disk drives themselves are creating fake geometry and passing it up. > I think that we just whatever BIOS/firmware/etc provides to us in some = way. For MBR and devices > 8GB, this should be ignored, since the fields = saturate (except ones created with our fdisk/sysinstall programs: then = they just size & 0x3ff the values for cylinders rather than the proper = 1023 saturation). >> After >> 9.0 branched, we can do a lot more knowing we have plenty >> of soak time... >=20 > I agree in general, but there is one thing I want now/ASAP - ability = to use gpart > to create (valid) partitions the way I like it disregarding whatever = fake geometry > there might be. I hate when tools go EDAVE on me. At this stage of the game, the boundary checks should be relaxed and = opt-in. We likely should just create MBR slices starting at 64 always, = unless someone has specifically requested that we align things, or asks = for a different starting place. Warner=