Date: Wed, 25 May 2011 18:22:42 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Marcel Moolenaar <xcllnt@mac.com>, Warner Losh <imp@bsdimp.com>, freebsd-geom@FreeBSD.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme Message-ID: <4DDD1EC2.7090405@FreeBSD.org> In-Reply-To: <4DDC049C.7070904@yandex.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDD1EC2.7090405>