From owner-freebsd-fs@FreeBSD.ORG Wed Jun 8 22:34:08 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87EDE106566C for ; Wed, 8 Jun 2011 22:34:08 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42B588FC08 for ; Wed, 8 Jun 2011 22:34:07 +0000 (UTC) Received: by yie13 with SMTP id 13so686481yie.13 for ; Wed, 08 Jun 2011 15:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=hhpHQiEdEcG6DU4CGxuyA9LReNcycWROrfbYfV8BbxQ=; b=tqg4hSOEhfzZE0JcyW1cybfiHCIonnjZh59+nUTW2EdEus8Adtu7prlGkDYIoyQixI eZ55nHSJR8PHK+eFFGoXKwU1PjXZlXwTa1OmHdDfMv6daA5W2a2Oy7k4lTcAUOMQrVEC puP9t5QCqjVqWR62qyZvtVISMTZ7uL0Cqabeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=EE0KNnt1alGEKHCyQdTa6ZJouehWpkrIREinMKtkQmmqFFMld1CVTyT1BY9zcbQblF elk4AMVeErEme4RxAdQyrhVby7venUOyxwgdyhsq2KfEWNSsHdVnso1SMIBXpUO4ww4b /j/O+AbVh7003I6OnVcNfBjBeD2As35bdYPuA= MIME-Version: 1.0 Received: by 10.100.51.8 with SMTP id y8mr1424788any.111.1307572447290; Wed, 08 Jun 2011 15:34:07 -0700 (PDT) Received: by 10.100.243.35 with HTTP; Wed, 8 Jun 2011 15:34:07 -0700 (PDT) In-Reply-To: <20110608075526.GA85577@icarus.home.lan> References: <20110608075526.GA85577@icarus.home.lan> Date: Wed, 8 Jun 2011 18:34:07 -0400 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: GPT and disk alignment X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 22:34:08 -0000 On Wed, Jun 8, 2011 at 3:55 AM, Jeremy Chadwick wrote: > On Wed, Jun 08, 2011 at 01:29:43AM -0400, Robert Simmons wrote: >> On Wed, Jun 8, 2011 at 12:29 AM, Mark Felder wrote: >> > On Tue, 07 Jun 2011 22:27:24 -0500, Robert Simmons >> > wrote: >> >> Do all HDDs that have 4KB per LBA present themselves to the OS as >> >> having 512 bytes per LBA? >> > >> > No >> >> Ok, but can I assume that all HDDs of this type expand each of the 4K >> sectors so that physically they take up the same space as eight 512 >> byte LBAs? =A0AFAIK, the new 4K LBA has a smaller ECC area than the sum >> of 8 ECC areas in 512 byte LBAs, so if the data area was _not_ >> expanded slightly, you would never really be aligned except every x >> LBAs as the shifting approaches an LBA boundary, right? >> >> For any HDDs, do I need to worry about cylinder boundaries at all? >> Has the reported "disk geometry" become divorced from the physical >> reality in modern disks? =A0If I do still need to worry about cylinder >> boundaries, should I basically ignore every reported geometry (BIOS, >> OS) and use what is written on the sticker on the drive? >> >> >> What about SSDs that have 1024 bytes per LBA? >> > >> > Not sure, but I do know that not all flash media have the same bytes p= er LBA >> > internally. Some are 1K, some 4K, some even 8K. GPT is definitely the = way to >> > go if you want to make sure you're aligned. >> >> Ok, is there some way to tell gpart(8) what the LBA size is, or do I >> have to calculate the offset of each partition manually? =A0In Linux it >> would be "fdisk -b 1024" for the example of SSDs or "fdisk -b 4096" >> for 4K HDDs. > > I would think you'd just use "gpart -b" to specify the base offset. > For example, on an Intel 320-series SSD (which uses a NAND flash cell > size of 8192 bytes), "gpart -b 8" should end up at byte 65536 within the > flash itself. > > I'm not sure if using 8 is correct though -- that is to say, I believe > there is other space near the beginning of the drive which is used for > things like the boot loader (I don't mean boot0, I mean boot2/loader and > friends), or for the GPT loader or GPT ZFS loader. =A0I could be wrong on > this part -- need someone to correct me. =A0All these different loaders > and GPT support on FreeBSD seriously makes my head spin. > > Anyway back to SSDs: > > I have yet to see anyone list off all the *actual* NAND flash cell sizes > of SSDs. =A0For example, everyone said "4KBytes" for Intel SSDs, but come > to find out it's actually 8KBytes. > > Don't confuse NAND flash cell size with NAND erase page size. =A0They're > two different things. =A0Multiple cells make up (fit into) a single erase > page. =A0The alignment issue only applies to the cell part, not the erase > page size. =A0(I just had a discussion with an end-user on Intel's forum > about this; someone had lead him to believe the erase page size was what > he should align to). > > For example, on Intel 320-series drives, the NAND erase page size is 256 > cells, thus 256*8192 =3D 2097152, or 2MBytes. =A0Just a technical FYI bit > for those curious. Thanks for the info. I have an OCZ vertex 2 drive. After looking on the OCZ forums and reading reams and reams of conflicting and uninformed posts, I decided to just call OCZ's support. I asked what the flash cell size is, and what the erase page size is (the guy I talked to didn't know much of what I was talking about and had to go talk to a superior). He came back and said that he was told that he's not allowed to give out that information, but that as long as I begin the first partition at LBA 64 everything will align properly. And that subsequent partitions should start at an LBA divisible by 64. So, if I do that, won't it also be aligned properly if the flash cell size is 4K or 8K, since 32K (LBA 64) is divisible by 4 & 8? Does a 32K flash cell size sound like nonsense? Could that be the erase page size for this drive?