On Wed, 23 May 2012, Tim Kientzle wrote:
On May 22, 2012, at 7:40 AM, Warren Block wrote:
On Tue, 22 May 2012, Matthias Apitz wrote:
El día Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block escribió:
On Tue, 22 May 2012, Matthias Apitz wrote:
El día Sunday, May 20, 2012 a las 03:36:01AM +0900, rozhuk...@gmail.com
escribió:
Do not use MBR (or manually do all to align).
63 - not 4k aligned.
To create the above shown partition layout I have not used gpart(8); I
just said:
# fdisk -I /dev/ada0
# fdisk -B /dev/ada0
...
What is wrong with this procedure?
The filesystem partitions end up at locations that aren't even multiples
of 4K. This can reduce performance. How much probably depends on the
SSD.
But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-)
A bug in the design of MBR. Which probably can be forgiven, considering when
it was created and the other problems with it. :)
gpart's alignment option can be used with MBR slices and bsdlabel partitions.
GPart's alignment option doesn't work for MBR slices.
It rounds to the requested alignment, and then rounds again
to the track size, which defaults to 63 sectors.
There's an example in my proposed rewrite of the Handbook RAID1
section: http://www.wonkity.com/~wblock/mirror/book.html
The slice starts at block 126, two blocks shy of 4K alignment. With the
added two blocks for the bsdlabel, all of the FreeBSD partitions end up
aligned at even 4K multiples.
A filesystem in the raw slice would be misaligned. Presumably the
answer is "well don't do that, then" (always use a bsdlabel with MBR),
or some trick to skip a couple of blocks like gnop.
If there are any mistakes in that example, please help me correct them
to avert steps 4 and 5 of the traditional commit process (4: apologize,
and 5: fix and recommit).
I'm not convinced this is a bug in the design of MBR. I don't
think anything in the MBR design requires that partitions
be track-aligned.
I meant "bug" in the sense of a missing feature. MBR may not have a
provision for fixed alignment, but to its credit, doesn't prevent it
either._______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
