Date: Fri, 25 May 2012 01:54:41 -0700 From: Julian Elischer <julian@freebsd.org> To: Warren Block <wblock@wonkity.com> Cc: Matthias Apitz <guru@unixarea.de>, freebsd-hackers@freebsd.org Subject: Re: proper newfs options for SSD disk Message-ID: <4FBF48D1.1050402@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1205240602540.53872@wonkity.com> References: <alpine.BSF.2.00.1205182209010.9350@wojtek.tensor.gdynia.pl> <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <alpine.BSF.2.00.1205220731070.51493@wonkity.com> <20120522134846.GA2274@tiny> <alpine.BSF.2.00.1205220837500.51493@wonkity.com> <CF851064-F78F-44AF-B562-32012E4DC043@kientzle.com> <alpine.BSF.2.00.1205240602540.53872@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.im@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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FBF48D1.1050402>