From owner-freebsd-geom@FreeBSD.ORG Wed May 25 18:03:08 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 68BCB1065673 for ; Wed, 25 May 2011 18:03:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C21068FC0A for ; Wed, 25 May 2011 18:03:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA02999; Wed, 25 May 2011 21:02:54 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1QPIQ2-000AeK-If; Wed, 25 May 2011 21:02:54 +0300 Message-ID: <4DDD444D.6020205@FreeBSD.org> Date: Wed, 25 May 2011 21:02:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110503 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Warner Losh 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> <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> In-Reply-To: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 18:03:08 -0000 on 25/05/2011 20:31 Warner Losh said the following: > > 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: >>>> >>>> On May 24, 2011, at 10:46 AM, Warner Losh wrote: >>>>>> All I'm saying: be careful. >>>>> >>>>> Agreed. But the care should be on the creation side, not on the >>>>> interpretation side. >>>> >>>> ... 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). >>> >>> 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. >> >> All the good points, IMO. >> >>>> With respect to the creation: >>>> >>>> Since out synthesized geometry is not necessarily the same as other >>>> OSes, we could opt to synthesize a geometry that has a track size (= >>>> 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. >>> >>> Today's devices do not report about their 4k sectors. >>> >>>> Thus: rather than hack MBR and forgetting about EBR and other >>> >>> I do not forget about EBR, PC98 and VTOC8. But we need begin from >>> something. >>> >>>> 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... >>> >>> Ok, i can revert all related changes and just do nothing :) It seems it >>> is better solution :) >> >> 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. >> >> 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. >> >> 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. Your 3 should be a sub-case of my 2 as it involves CHS parameters. >> 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. I would agree with your suggestion, but I am trying to find a consensus with Marcel and his POLA concerns. >> 3. Keep all non-CHS validations and sanity checks, of course. >> >> Long term (post-9 ?): 1. Change defaults to play nicer with modern disks >> >> 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. OK. Excluding the special cases. -- Andriy Gapon