Date: Wed, 25 May 2011 21:02:53 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> 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: <4DDD444D.6020205@FreeBSD.org> In-Reply-To: <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com> 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> <0EFCF6E2-9150-4756-8DE1-5EE70EC22C8D@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDD444D.6020205>