Partition alignment

[Lawrence K. Chen, P.Eng.]

On 03/26/14 17:38, Andrea Venturoli wrote:
> On 03/26/14 22:59, Warren Block wrote:
> 
>> No.  The starting blocks of the slice and partition are added together
>> to determine the actual start block of the partition:
>> The first partition begins at 63+0, or 63.  63*512 = 32256, not evenly
>> divisible by 4K.  Or just divide the block number by 8, same thing.
> 
> Ok.
> That 63 was the one that was worrying me...
> 
> I'm wondering what's the rationale behind it (it was created by 8.4's
> sysinstall); is it so to leave space for the MBR (or whatever boot block type)?
> 
Traditionally, your data started on track 1, and in traditional CHS, there's a
maximum of 63 sectors per track (and maximum of 255 heads), so that makes the
first sector of track 1, 63.

The maximum of 63 comes from the IBM PC BIOS which encoded sectors in 6 bits,
but started number sectors from 1.  While software, like fdisk, number sectors
from 0.

In addition to the boot block at the start of track 0, other data has made its
way into this track,  Used to have a hardware raid controller that used sector
1, which didn't get along when I tried an OS that put its bootcode after the
bootblock starting at 1.  Ended up losing the controller and the mirror...and
the drive out lived the OS.

> Should I leave more space and start the slice at 256kB?
> 
> 
> 
>> When creating the partitions, use gpart's -a option, and it will add an
>> offset so the slice is aligned:
>>
>> gpart add -t freebsd-ufs -a4k -s8g mfid0s1
> 
> So you are suggesting I could leave the slice where it is, and just move the
> partitions?
> 
I think that's what to do in the future...Not sure if gpart will know that the
slice is misaligned when deciding how to adjust the start offsets to make
aligned partitions within.

> Shouldn't I use -a256k, since that's the stripe size?
> 
> 
Sure, that would probably be best.

On another OS, fdisk has an alternative to cylinder based formatting of MiB
based format, which uses multiples of 2048.

Seems kind of wasteful, though I guess I'm still from when 8MB was a lot of
space (its still the unix home directory quota here.)

Since I neglected to pay attention to this when I set up my first server, I've
been trying to work out how to shift partitions into alignment without
downtime.  I had created the zroot zpool using gnop, so its ashift is 12, but
the partitions aren't 4k aligned.

I did create swap partitions external to ZFS (should these be aligned as
well?)  Thinking when there's a quiet moment, to yank out the swap partitions,
realign and shrink.  Then detach one mirror, realign, reattach, resilver and
then repeat for the other.

And, can it be as simple as shift the swap partition down to 168 (21*8)...+6,
trim off 8 sectors from its size so that ZFS partition starts up 2 sectors...

So that this:

=>       34  468862061  ada0  GPT  (223G)
         34        128     1  freebsd-boot  (64k)
        162   33554432     2  freebsd-swap  (16G)
   33554594  435307501     3  freebsd-zfs  (207G)

becomes:

=>       34  468862061  ada0  GPT  (223G)
         34        128     1  freebsd-boot  (64k)
        168   33554424     2  freebsd-swap  (16G)
   33554592  435307501     3  freebsd-zfs  (207G)
  468862093          2        - free - (1.0k)

Just have to work up the nerve....figured freebsd-boot can stay.

Also this is a (pair) 240G SSD, so wonder if I should also see if what page
size they use and whether EBS alignment is important.

They both seem to claim to be 512 physical and logical, though diskinfo
reports stripesize of 4096 for one, and 0 for the other....the other being
OCZ, which I've heard is 8K pages and 2MB EBS.

So, do I 8K align things...1MB/2MB?

Wonder if gpart truncates the tweaked swap partition size to show (15G) next
to it?

> 
>  bye & Thanks
>     av.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally