[ale] OT: WD "Advanced Format" and "Green Drives"

[Michael Trausch]

On Mon, 2010-04-12 at 08:57 -0400, Greg Freemyer wrote:
> On Fri, Apr 9, 2010 at 5:31 PM, Michael Trausch <mike at trausch.us> wrote:
> > On Fri, 2010-04-09 at 13:45 -0400, Greg Freemyer wrote:
> >> I would avoid drives with 4KiB physical blocks for a while longer
> >> unless you want to take extra care about alignment etc.
> >
> > It should not be a great issue; the only thing that you have to be sure
> > about is to align the start of a partition correctly.  The ext2/3/4
> > family of filesystems already uses 4KiB blocks by default for many
> > configurations, and so honestly the only real care that you have to take
> > is to be sure that the start of the first 4KiB block is on a native
> > boundary.
> 
> Surprisingly some of the partitioning tools fail if you try to work
> with partitions that don't follow their preconceptions about how the
> start and end of partitions should align with cylinders.

It's not (terribly) surprising, though if memory serves, you can tell
the programs (at least fdisk and sfdisk) to ignore their notions and
safety checks, and they will do so.  I'd need to read the man page to be
sure, something which I have not yet had enough coffee to do.  :-)

> sfdisk and cfdisk have neither been updated to be more flexible.

cfdisk is pretty strict; it expects partitions to land on even
boundaries, for example (which they should anyway).

> Below is a cut and paste from a lkml email from just last week.  Note
> the fatal error at the end.
> 
> ===
> I created this partition table using cfdisk (util-linux 2.17 from
> debian/experimental). I guess even that is too old?
> 
> I now re-created the partition table using fdisk from util-linux-ng
> git and got this:
> 
> Command (m for help): p
> 
> Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
> 81 heads, 63 sectors/track, 765633 cylinders, total 3907029168 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x2afff6d1
> 
>   Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1            2048  3907029167  1953513560   83  Linux
> 
> but:
> 
> 
> $ sudo cfdisk -P s /dev/sdb
> FATAL ERROR: Bad primary partition 0: Partition ends in the final
> partial cylinder
> 
> ===

Yes, and that is wholly unsurprising.  cfdisk will make this complaint
with any partition that has been created with a tool that lands a
partition this way, though the reasons are mostly historical as I
understand it.  cfdisk is designed to be more-or-less end-user facing.
Had they used "cfdisk -z" and created a single partition, they would
have gotten a partition that was properly constructed (that is, with the
final sector on the last sector of the second-to-last cylinder on the
disk).  Again, I don't recall _why_ that's the historic convention, but
I _do_ recall that there was at least once upon a time a reason for it.

> I'm not saying its real hard to work with 4K physical sector drives,
> but it does introduce problems with little or no benefit.
> 
> Or if there is benefit, what is it?

AIUI, it has to do with "sector death".  That is, failure rates for
sectors have stayed relatively constant, but (obviously) the number of
sectors on-disk has grown over the past several years---leading to the
same rates of failure on a sector-by-sector level, but higher rates of
failure in terms of per disk.

So, a drive with 4,096 byte sectors is going to have fewer sectors, but
a relatively same-sized spare sector store (in terms of the number of
sectors) and should be able to tolerate losing more bytes (though fewer
sectors).  Since sector failures (at least in my experience) tend to
have sequential runs to them, I imagine that this would have at least
some benefit.

There is also the idea that there will be more available storage given a
platter that has the same number of bytes on it, because there is
reduced overhead for things like per-sector data storage overhead on the
platter.

Here's one site that talks about it in a bit more detail:

  http://www.anandtech.com/show/2888

I read some other stuff "directly from the horse's mouth" some time
back, but I cannot find the links.

	--- Mike