From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S4fYi-0004na-Qn for garchives@archives.gentoo.org; Mon, 05 Mar 2012 21:35:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 62299E0761; Mon, 5 Mar 2012 21:34:56 +0000 (UTC) Received: from mail-vx0-f181.google.com (mail-vx0-f181.google.com [209.85.220.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 7B667E06FC for ; Mon, 5 Mar 2012 21:33:52 +0000 (UTC) Received: by vcge1 with SMTP id e1so3188734vcg.40 for ; Mon, 05 Mar 2012 13:33:52 -0800 (PST) Received-SPF: pass (google.com: domain of poisonbl@gmail.com designates 10.52.88.212 as permitted sender) client-ip=10.52.88.212; Authentication-Results: mr.google.com; spf=pass (google.com: domain of poisonbl@gmail.com designates 10.52.88.212 as permitted sender) smtp.mail=poisonbl@gmail.com; dkim=pass header.i=poisonbl@gmail.com Received: from mr.google.com ([10.52.88.212]) by 10.52.88.212 with SMTP id bi20mr37549117vdb.2.1330983232001 (num_hops = 1); Mon, 05 Mar 2012 13:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=tga9RX3twNItfLWiMWPTFyPw/lw61tYarQEX60GcQ10=; b=ij81aYWLDpoEpF/m/u5u7KaAgk+oeF/NtRP1ot1lN5joaPPygdLsf4WL34bUu21j78 9HVwYPNluCyyXyd3eh6+IMs8uOv6GR7DOURpIkcNeCpp3b7yWhlqjb2FPDV/EHx9VAYG ISPWlyE1rHHYk2Rdynb9n2QdSU/M6LSgCmPWNYEhDLs9I1xrcKokhXZZafRtEzZ/APtp Fczh/jHo2iEDZ90f3gtHJsAi5OW6o5s9/a+FugjWXhx/M/X1eFZz46JXmRhu+vPjY5+v h7nyVVUJzd/gUXMLNZ51lc/F+vBIsGKJe903ytH6QF6Rqf772eYDaFXVVHL0/foqDRL0 99Vg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.88.212 with SMTP id bi20mr32112263vdb.2.1330983231941; Mon, 05 Mar 2012 13:33:51 -0800 (PST) Received: by 10.220.182.6 with HTTP; Mon, 5 Mar 2012 13:33:51 -0800 (PST) In-Reply-To: <20120305170057.7c47b2a4@weird.wonkology.org> References: <20120305170057.7c47b2a4@weird.wonkology.org> Date: Mon, 5 Mar 2012 16:33:51 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Gentoo on a Dell XPS 13 Ultrabook From: Joshua Murphy To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 16b936d5-e926-4378-9de8-afaaf398f577 X-Archives-Hash: ed0f19a5601225463fefd92d4caebc34 On Mon, Mar 5, 2012 at 11:00 AM, Alex Schuster wrote: > Grant writes: > >> > The performance is only impacted if the sector size is something other >> > =C2=A0than 512 bytes. The newer 4K sector size used by some higher den= sity >> > drives requires that you start partitions on a sector boundary or they >> > will perform badly. There isn't an actually performance need to >> > actually start on 2048 but the fdisk-type developer folks are doing >> > that to be more compatible with newer Windows installations. >> >> All my drives says this from fdisk: >> >> Units =3D sectors of 1 * 512 =3D 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes > > Neither fdisk nor hdparm seem to get the correct sector size, at least > not always. That's what I read somewhere (and not only once), and it's > true for my own 2TB drive which I know to have a 4K sector size. I'd say > you have to look up the specs on the vendor's web size to be sure. > >> So it doesn't matter where the first partition starts? > > If you have 4K sectors (and not a Seagate drive with SmartAlign [*]), it > does. > > BTW, here's some benchmarks I just stumbled upon: > http://hothardware.com/Articles/WDs-1TB-Caviar-Green-w-Advanced-Format-Wi= ndows-XP-Users-Pay-Attention/?page=3D2 > > [*] I don't want to sound like I'm advertising for Seagate here, but at > least it seems that with SmartAlign the performance impact will be > much less, so it might not be worth the trouble of re-partitioning drives > that are already being used. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Wonko Also, it counts with SSDs, where alignment,or lack therof, with the erase block becomes noticeable on write performance. Finding the actual size of an erase block for most SSDs is rather difficult, but 1MB tends to be a reliable guess as a multiple of *that* as well. --=20 Poison [BLX] Joshua M. Murphy