Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2011 11:46:06 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Marcel Moolenaar <xcllnt@mac.com>
Cc:        "Andrey V. Elsukov" <bu7cher@yandex.ru>, Andriy Gapon <avg@FreeBSD.org>, freebsd-geom@FreeBSD.org
Subject:   Re: [RFC] Remove requirement of alignment to track from MBR scheme
Message-ID:  <2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC@bsdimp.com>
In-Reply-To: <D7C4124D-A690-4960-B141-594C7E2BE792@mac.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>

next in thread | previous in thread | raw e-mail | index | archive | help

On May 24, 2011, at 10:35 AM, Marcel Moolenaar wrote:

>=20
> On May 23, 2011, at 11:43 PM, Andriy Gapon wrote:
>=20
>> on 23/05/2011 20:38 Warner Losh said the following:
>>>=20
>>> 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.
>>=20
>> _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.
>=20
> :-)
>=20
> Well, I just initialized a USB stick on my Mac and I see that it
> still adheres to some notion of geometry:
>=20
> 	:
> ugen3.2: <ITE Tech Inc.> at usbus3
> umass0: <ITE Tech Inc. USB FLASH STORAGE, class 0/0, rev 2.00/2.00, =
addr 2> on usbus3
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <Simple Bonzai Xpress 2.20> Removable Direct Access SCSI-2 device=20=

> da0: 1.000MB/s transfers
> da0: 499MB (1023484 512 byte sectors: 64H 32S/T 499C)
> GEOM: da0s1: EBR has non empty bootcode.
> GEOM: msdosfs/MAC: EBR has non empty bootcode.
> marcelm-server% gpart show da0
> =3D>     32  1023424  da0  MBR  (499M)
>       32       31       - free -  (15k)
>       63  1023372    1  fat32  (499M)
>  1023435       21       - free -  (10k)

does fdisk report the same thing?  When I was poking, the 16GB stick I =
have reported something similar to this via gpart show, but showed there =
was nothing at the end when reported with fdisk.

> gpart synthesized a 64 head, 32 sectors/track geometry, which
> is not the same as the 63 sectors/track that Mac synthesized.
> Yes, this demonstrates the bogosity of geometry, but it also
> shows that it still exists.

It still exists, but on the other hand it isn't *that* useful...

> All I'm saying: be careful.

Agreed.  But the care should be on the creation side, not on the =
interpretation side.  In general, we should believe what the MBR says =
and not do the kinds of rounding we do with creation.  Also, I think =
that we should allow non-aligned to fake geometry creations if the user =
desires (or maybe even go so far as to make that the default and have =
alignment forcing be a requested behavior).

Warner

> --=20
> Marcel Moolenaar
> xcllnt@mac.com
>=20
>=20
>=20
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FCA1E3C-E11C-46C9-A41B-E5DF4D8BA1FC>