From owner-freebsd-geom@FreeBSD.ORG Tue May 24 18:12:30 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 6D1C31065670; Tue, 24 May 2011 18:12:30 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 507028FC0A; Tue, 24 May 2011 18:12:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from sa-nc-common-178.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLP0043XP85FC60@asmtp028.mac.com>; Tue, 24 May 2011 11:12:07 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.148,0.0.0000 definitions=2011-05-24_06:2011-05-24, 2011-05-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1105240114 From: Marcel Moolenaar In-reply-to: <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> Date: Tue, 24 May 2011 11:12:10 -0700 Message-id: <9B250685-62F2-4AF7-BDCC-D176FA3C6FCD@mac.com> References: <4DDA2F0B.2040203@yandex.ru> <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> <4DDB5375.6050004@FreeBSD.org> <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1084) Cc: "Andrey V. Elsukov" , Andriy Gapon , 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: Tue, 24 May 2011 18:12:30 -0000 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). 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. Thus: rather than hack MBR and forgetting about EBR and other 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... -- Marcel Moolenaar xcllnt@mac.com