[Top] [All Lists]

Re: 4k drives: benefits and models?

To: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Subject: Re: 4k drives: benefits and models?
From: Emmanuel Florac <eflorac@xxxxxxxxxxxxxx>
Date: Mon, 26 Jul 2010 12:07:08 +0200
Cc: Linux XFS <xfs@xxxxxxxxxxx>
In-reply-to: <19533.22251.225560.835077@xxxxxxxxxxxxxxxxxx>
Organization: Intellique
References: <20100726082141.GA8239@xxxxxxxxxx> <19533.22251.225560.835077@xxxxxxxxxxxxxxxxxx>
Le Mon, 26 Jul 2010 10:35:39 +0100
pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi) écrivait:

> It is purely higher density. A longer physical sector means less
> percentage of the disk is "wasted" on metadata. This benefits
> the manufacturer mostly, so they can claim more capacity with
> less cost (but more credibly than the far more slimy trick of
> LCD manufacturers who are going to ever more extreme landscape
> ratios to claim a longer diagonal with less pixels).

It isn't actually that simple. By keeping the same metadata ratio, the
largest correctable error goes up from 10 bytes to 80 bytes. That means
taht the new drives should be much less prone to uncorrectable ECC
errors, which are the real culprit with the previous generation of big
drives (Seagate barracuda 1, 1.5 and 2TB are particularly terrible IMO).

> From the user/filesystem point iof view it is not a positive
> thing, but since the 4BSD FFS introduced 4KiB blocks (a very bad
> idea) and intel and others followed throught with alrge 4KiB
> pages that has been largely irrelevant.

This was eons ago, I'm pretty sure we managed to live with it :) What
was problematic back when disks drives were in the hundreds of
megabytes isn't so much a problem when the smallest drives available
(146 GB) are 1000 times bigger. Many filesystems use much bigger blocks
on bigger filesystems, too (NTFS anyone? WS2003 can use 16, 32 or even
64 KB).

Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |   <eflorac@xxxxxxxxxxxxxx>
                    |   +33 1 78 94 84 02

<Prev in Thread] Current Thread [Next in Thread>