On 5/24/12 5:35 AM, Warren Block wrote:
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.
WAAAAYYY back when disk drives and BIOS cared about this the size of
a track was signalled past various scope barriers to the actual driver
by setting the sectors per-track and heads-per-drive to the maximum
values for that actual drive..
i.e. we assumed that the partition ENDED on a cylinder boundary and
used that to extrapolate the actual geometry, which the driver
actually needed to be able to drive the driver correctly. (a block
number had to be divided into cyls and heads to get teh right place to
go to.)
none of that is true any more on any drive we care about and even if
it was we can now read bios tables.
so we can stick the damned partitions where ever we want, and Even the
BIOS can find them (since mid 90's)..
yeah I wrote it.. about time to remove it..
take that 63/255 out and shoot it.
_______________________________________________
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"
_______________________________________________
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"
