Date: Wed, 25 May 2011 11:31:41 -0600 From: Warner Losh <imp@bsdimp.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, Marcel Moolenaar <xcllnt@mac.com>, freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme Message-ID: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> In-Reply-To: <4DDD1EC2.7090405@FreeBSD.org> References: <4DDA2F0B.2040203@yandex.ru> <D75B2856-D9D8-4BA3-BC54-8258610CEA06@xcllnt.net> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <D7C4124D-A690-4960-B141-594C7E2BE792@mac.com> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> <4DDC049C.7070904@yandex.ru> <4DDD1EC2.7090405@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D>