Date: Thu, 12 May 2011 22:23:16 +0300 From: Alexander Motin <mav@FreeBSD.org> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= <uqs@spoerlein.net>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r221363 - head/sbin/geom/class/part Message-ID: <4DCC33A4.4040301@FreeBSD.org> In-Reply-To: <4DCC0273.6010904@FreeBSD.org> References: <201105030733.p437XduH075011@svn.freebsd.org> <20110512151508.GK11355@acme.spoerlein.net> <4DCC0273.6010904@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12.05.2011 18:53, Andrey V. Elsukov wrote: > On 12.05.2011 19:15, Ulrich Spörlein wrote: >>> Add "-a alignment" option to gpart(8). When it specified gpart(8) >>> tries to align partition start offset and size to be multiple of >>> alignment value. >>> >> >> Aligned to what? The disk or the partition scheme? Consider someone >> having a GELI partition of arbitrary alignment, how would a bsdlabel or >> GPT label inside this GELI partition be aligned when 4K alignment is >> requested? > > Each partition has three mandatory parameters: start offset, end offset > and partition type. These offsets are within top level provider. With 4K > alignment gpart(8) would try to adjust partition start and end offset to > be multiple of 4K. Most of GEOM classes report enough alignment data (stripesize and stripeoffset). They should be taken to account to properly handle alignment partitions on cascaded partitioned tables (bsdlabel inside MBR). -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DCC33A4.4040301>