From owner-freebsd-hackers@FreeBSD.ORG Thu May 24 04:49:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E19106566B for ; Thu, 24 May 2012 04:49:17 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 04DA88FC08 for ; Thu, 24 May 2012 04:49:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4O4nF3C048368; Thu, 24 May 2012 04:49:15 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id m9m7p95eywmy63444kvkjpaxvw; Thu, 24 May 2012 04:49:15 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Tim Kientzle In-Reply-To: Date: Wed, 23 May 2012 21:49:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4fb7dfd6.736a980a.186d.ffff902f@mx.google.com> <20120519180901.GA1264@tiny> <4fb7e819.6968700a.7a7f.ffff9153@mx.google.com> <20120522061734.GA1210@tiny> <20120522134846.GA2274@tiny> To: Warren Block X-Mailer: Apple Mail (2.1278) Cc: freebsd-hackers@freebsd.org, Matthias Apitz Subject: Re: proper newfs options for SSD disk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 04:49:17 -0000 On May 22, 2012, at 7:40 AM, Warren Block wrote: > On Tue, 22 May 2012, Matthias Apitz wrote: >=20 >> El d=EDa Tuesday, May 22, 2012 a las 07:42:18AM -0600, Warren Block = escribi=F3: >>=20 >>> On Tue, 22 May 2012, Matthias Apitz wrote: >>>=20 >>>> El d=EDa Sunday, May 20, 2012 a las 03:36:01AM +0900, = rozhuk.im@gmail.com escribi=F3: >>>>>=20 >>>>> Do not use MBR (or manually do all to align). >>>>> 63 - not 4k aligned. >>>>=20 >>>> To create the above shown partition layout I have not used = gpart(8); I >>>> just said: >>>>=20 >>>> # fdisk -I /dev/ada0 >>>> # fdisk -B /dev/ada0 >>>>=20 >>>> ... >>>> What is wrong with this procedure? >>>=20 >>> 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. >>=20 >> But this is then rather a bug in fdisk(8) and not a PEBKAC, or? :-) >=20 > A bug in the design of MBR. Which probably can be forgiven, = considering when it was created and the other problems with it. :) >=20 > 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. 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. Tim