From owner-freebsd-geom@FreeBSD.ORG Wed May 25 17:36:28 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 7EFDF1065670; Wed, 25 May 2011 17:36:28 +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 2B86B8FC08; Wed, 25 May 2011 17:36:28 +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 p4PHVlb3031573 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 11:31:49 -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: <4DDD1EC2.7090405@FreeBSD.org> Date: Wed, 25 May 2011 11:31:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@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> <4DDC049C.7070904@yandex.ru> <4DDD1EC2.7090405@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:31:50 -0600 (MDT) Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@FreeBSD.org 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:36:28 -0000 On May 25, 2011, at 9:22 AM, Andriy Gapon wrote: > on 24/05/2011 22:18 Andrey V. Elsukov said the following: >> On 24.05.2011 22:12, Marcel Moolenaar wrote: >>>=20 >>> On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>>>> All I'm saying: be careful. >>>>=20 >>>> Agreed. But the care should be on the creation side, not on the = interpretation side. >>>=20 >>> ... as the original code was. We just need to add a sanity >>> check to the interpretation that filters out the real bogus >>> information (resulting in a partition with negative size). >>=20 >> A partition with negative size is not the one problem. >> Some time ago i found an easy reproducible bug, when BSD scheme >> creates providers with size bigger than parent provider size. >> Also there was nothing against creation of overlapped partitions. >=20 > All the good points, IMO. >=20 >>> 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 >> Today's devices do not report about their 4k sectors. >>=20 >>> Thus: rather than hack MBR and forgetting about EBR and other >>=20 >> I do not forget about EBR, PC98 and VTOC8. But we need begin from = something. >>=20 >>> schemes, maybe we only have to tweak the geometry synthesis >>> to give people what they want without going over board. After >>> 9.0 branched, we can do a lot more knowing we have plenty >>> of soak time... >>=20 >> Ok, i can revert all related changes and just do nothing :) >> It seems it is better solution :) >=20 > I hope that you won't take the easy road and won't give up. > It's easy to say "don't change things", but sometimes reality presses = hard for a > change and there should be someone brave to make it. >=20 > I think that we are starting to reach some consensus here. > Let me try to summarize and check if this is what we indeed can agree = upon. >=20 > For media tasting/validation: > 1. Keep all the non-CHS LBA-based checks - too large partitions, = overlapping > partitions, etc. Perhaps add even more. And, of course, with proper = diagnostics. > 2. Ditch all the checks based on or involving CHS parameters. 3. Stop rounding to the nearest track when READING MBR. It is totally = bogus, never necessary and no documentation of the MBR has been produced = suggesting that you need to do this. If you don't think it is valid, = don't use it, but don't silently adjust it by a random amount leading to = hard to track down bugs. > For media creation, short term: > 1. By default be compatible with present behavior. > 2. Provide a way for a user to disable all CHS-based = validations/adjustments of > input parameters. Do not adjust based on CHS at all. The adjustments are almost always = bogus. In fact, I can't think of a time when the MBR ending track = should be adjusted when reading it from disk. Can you provide = justification for doing this that's backed up by some source that says = "the MBR values are adjusted like ..." rather than "MBR values are = aligned" I've yet to find one that says this adjustment is anything = but totally bogus on the read it from disk path. > 3. Keep all non-CHS validations and sanity checks, of course. >=20 > Long term (post-9 ?): > 1. Change defaults to play nicer with modern disks >=20 > Longer term: > 1. Possibly remove any CHS reference from all the code, kernel and = userland; > invent better heuristic values for things like partitioning, UFS = newfs, etc. You can't do that. CHS are still needed for sunlabel and pc98 support. Warner=