GPT and disk alignment

[Robert Simmons]

On Wed, Jun 8, 2011 at 3:55 AM, Jeremy Chadwick
<freebsd at jdc.parodius.com> wrote:
> On Wed, Jun 08, 2011 at 01:29:43AM -0400, Robert Simmons wrote:
>> On Wed, Jun 8, 2011 at 12:29 AM, Mark Felder <feld at feld.me> wrote:
>> > On Tue, 07 Jun 2011 22:27:24 -0500, Robert Simmons <rsimmons0 at gmail.com>
>> > wrote:
>> >> Do all HDDs that have 4KB per LBA present themselves to the OS as
>> >> having 512 bytes per LBA?
>> >
>> > No
>>
>> Ok, but can I assume that all HDDs of this type expand each of the 4K
>> sectors so that physically they take up the same space as eight 512
>> byte LBAs?  AFAIK, the new 4K LBA has a smaller ECC area than the sum
>> of 8 ECC areas in 512 byte LBAs, so if the data area was _not_
>> expanded slightly, you would never really be aligned except every x
>> LBAs as the shifting approaches an LBA boundary, right?
>>
>> For any HDDs, do I need to worry about cylinder boundaries at all?
>> Has the reported "disk geometry" become divorced from the physical
>> reality in modern disks?  If I do still need to worry about cylinder
>> boundaries, should I basically ignore every reported geometry (BIOS,
>> OS) and use what is written on the sticker on the drive?
>>
>> >> What about SSDs that have 1024 bytes per LBA?
>> >
>> > Not sure, but I do know that not all flash media have the same bytes per LBA
>> > internally. Some are 1K, some 4K, some even 8K. GPT is definitely the way to
>> > go if you want to make sure you're aligned.
>>
>> Ok, is there some way to tell gpart(8) what the LBA size is, or do I
>> have to calculate the offset of each partition manually?  In Linux it
>> would be "fdisk -b 1024" for the example of SSDs or "fdisk -b 4096"
>> for 4K HDDs.
>
> I would think you'd just use "gpart -b" to specify the base offset.
> For example, on an Intel 320-series SSD (which uses a NAND flash cell
> size of 8192 bytes), "gpart -b 8" should end up at byte 65536 within the
> flash itself.
>
> I'm not sure if using 8 is correct though -- that is to say, I believe
> there is other space near the beginning of the drive which is used for
> things like the boot loader (I don't mean boot0, I mean boot2/loader and
> friends), or for the GPT loader or GPT ZFS loader.  I could be wrong on
> this part -- need someone to correct me.  All these different loaders
> and GPT support on FreeBSD seriously makes my head spin.
>
> Anyway back to SSDs:
>
> I have yet to see anyone list off all the *actual* NAND flash cell sizes
> of SSDs.  For example, everyone said "4KBytes" for Intel SSDs, but come
> to find out it's actually 8KBytes.
>
> Don't confuse NAND flash cell size with NAND erase page size.  They're
> two different things.  Multiple cells make up (fit into) a single erase
> page.  The alignment issue only applies to the cell part, not the erase
> page size.  (I just had a discussion with an end-user on Intel's forum
> about this; someone had lead him to believe the erase page size was what
> he should align to).
>
> For example, on Intel 320-series drives, the NAND erase page size is 256
> cells, thus 256*8192 = 2097152, or 2MBytes.  Just a technical FYI bit
> for those curious.

Thanks for the info.  I have an OCZ vertex 2 drive.  After looking on
the OCZ forums and reading reams and reams of conflicting and
uninformed posts, I decided to just call OCZ's support.  I asked what
the flash cell size is, and what the erase page size is (the guy I
talked to didn't know much of what I was talking about and had to go
talk to a superior). He came back and said that he was told that he's
not allowed to give out that information, but that as long as I begin
the first partition at LBA 64 everything will align properly.  And
that subsequent partitions should start at an LBA divisible by 64.

So, if I do that, won't it also be aligned properly if the flash cell
size is 4K or 8K, since 32K (LBA 64) is divisible by 4 & 8?

Does a 32K flash cell size sound like nonsense?

Could that be the erase page size for this drive?