[RFC] Remove requirement of alignment to track from MBR scheme

Andrey V. Elsukov bu7cher at yandex.ru
Tue May 24 09:04:59 UTC 2011


On 24.05.2011 10:43, Andriy Gapon wrote:
>> On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote:
>>> I think we've had enough rushed and ill thought-out changes going
>>> in already and I can see that not aligning MBR partitions on a track
>>> boundary is potentially perceived as a PITA violation.
> 
> _PITA_ violation? :-)
> As to POLA - yeah, I can see people getting astonished that finally FreeBSD got
> its sh*t together and did the right thing, years after all other OSes (even
> Winddows) had done it.
> 
>> I can understand only generating MBRs on a track boundary.
> 
> No.  E.g. I wanted to create a 4KB aligned MBR slice, but our tools insisted on
> using a 63 sector alignment.  In fact, the value that I provided was silently
> rounded to the value that gpart thought was best for me.
> Really, if a user says to gpart "do whatever alignment you want", then I could
> see using geometry-based values, but I still think that we should not do that
> even in that case, I think we would be better off using some nice 2^N alignment.
> If a user says "use this alignment or slice start", then the tool should just
> shut up and do exactly what the user told it.

There are several operations which can/should be changed:
1. MBR detection. All users want keep their partitions accessible.
But with r221788 it is now problematic. I can revert r221788, but for
me it seems right and instead reverting MBR support should be changed:
	a) table->gpt_last should not be aligned to track boundary;
	b) table->gpt_first can be aligned to track for compatibility, but
	   if there is already some partition starts from inside first
	   track, table->gpt_first should be set to 1.

2. MBR creating.
	a) table->gpt_last should not be aligned to track boundary;
	b) table->gpt_first can be aligned to track for compatibility.

3. Creating partitions. Users should choose alignment method, not the kernel.
and they can do it:
	Align to 4k:
	# gpart add -t freebsd -a 4k -s 5g ada0
	
	Align according to disk geometry:
	# gpart add -t freebsd -g -s 5g ada0

So, patch is here:
	http://people.freebsd.org/~ae/mbr_geometry.diff

Examples:

# gpart create -s mbr md0
md0 created
# gpart show md0
=>        63  4294967232  md0  MBR  (5.5T)
          63  4294967232       - free -  (2T)

# gpart add -t freebsd -s 10g -a 4k md0
md0s1 added
# gpart show md0
=>        63  4294967232  md0  MBR  (5.5T)
          63           1       - free -  (512B)
          64    20971520    1  freebsd  (10G)
    20971584  4273995711       - free -  (2T)

# gpart add -t freebsd -s 10g -g md0
md0s2 added
# gpart show md0
=>        63  4294967232  md0  MBR  (5.5T)
          63           1       - free -  (512B)
          64    20971520    1  freebsd  (10G)
    20971584          45       - free -  (22k)
    20971629    20971503    2  freebsd  (10G)
    41943132  4253024163       - free -  (2T)

-- 
WBR, Andrey V. Elsukov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20110524/1688d78d/signature.pgp


More information about the freebsd-geom mailing list