From: Emmanuel Florac <eflorac@intellique.com>
To: Peter Grandi <pg_xf2@xf2.for.sabi.co.UK>
Cc: Linux XFS <xfs@oss.sgi.com>
Subject: Re: 4k drives: benefits and models?
Date: Mon, 26 Jul 2010 12:07:08 +0200 [thread overview]
Message-ID: <20100726120708.53ac63e3@harpe.intellique.com> (raw)
In-Reply-To: <19533.22251.225560.835077@tree.ty.sabi.co.uk>
Le Mon, 26 Jul 2010 10:35:39 +0100
pg_xf2@xf2.for.sabi.co.UK (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@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-07-26 10:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100726082141.GA8239@apartia.fr>
2010-07-26 9:05 ` 4k drives: benefits and models? Michael Monnerie
2010-07-26 9:35 ` Peter Grandi
2010-07-26 10:07 ` Emmanuel Florac [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100726120708.53ac63e3@harpe.intellique.com \
--to=eflorac@intellique.com \
--cc=pg_xf2@xf2.for.sabi.co.UK \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox