linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Norman Diamond" <ndiamond@wta.att.ne.jp>
To: <linux-kernel@vger.kernel.org>, <jw@pegasys.ws>,
	"Mudama, Eric" <eric_mudama@Maxtor.com>
Subject: Re: Blockbusting news, results end
Date: Tue, 28 Oct 2003 20:31:20 +0900	[thread overview]
Message-ID: <058d01c39d47$39becbb0$f3ee4ca5@DIAMONDLX60> (raw)

jw schultz wrote:

> > I am assuming that these numbers are applicable (one is
> > unknown):
> > logical sector size == 512B
> > physical sector size == ???B
> > page size/filesystem block size == 4KB
>
> I have dialoged with Eric Mudama.  He is 99% sure that no
> manufacturer of is making ATA drives with physical sectors
> larger than 512B.  I'll let that statement trump Norman
> Diamond's until i hear otherwise.

Someone else in this discussion estimated that physical sectors are around
1MB these days.  My friends at Toshiba confirmed that physical sectors are
much larger than logical sectors.  The physical sector size resembles that
1MB estimate far better than the 512B logical sector size.

> The drive manufacturers would like to be able to go to a
> larger physical sector but the read-modify-write is just too
> scary.

It is really hard to imagine a physical sector still being 512B because the
inter-sector gaps would take some huge multiple of the space occupied by the
sectors.  I think this discussion has proved that we need to be scared of
read-modify-writes, but I think the drive manufacturers are doing it even
though it is scary.

> If they could be sure of market acceptance of drives
> that required all I/O to be in larger units they would build
> them because it would allow greater capacity (and i'm
> guessing speed as well) on the same physical hardware.

No, the effect on speed is the opposite.  A simple write could be done with
one seek and a random fraction of a rotational delay.  A read-modify-write
requires one seek and a random fraction plus additional entire rotational
delay.

I want to ask my friends why the read-modify-write behavior changed between
a 512B write and a 4096B write.  When the drive finally reallocated the
defective sector, it was during a 4096B write.  But I don't think they'll be
allowed to answer.  They already weren't allowed to talk much about the
firmware, but they did confirm that my original complaints about the
defective firmware were pretty accurate.

By the way, a few years ago when I visited other departments at Toshiba's
local division, I walked past a lot of ordinary large open-layout offices,
and also walked past one highly secured door.  That door had a sign on it
(in Japanese) saying that entry was prohibited to anyone not working on disk
drive design.  The accidental occurences by which I became friends with some
of their disk drive engineers were not a result of those business visits.
Probably there is no way that Toshiba would ever officially publicize even
the limited amount of information that my friends admitted to.  Nonetheless,
I'm sure the physical sectors are not 512B.


             reply	other threads:[~2003-10-28 11:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-28 11:31 Norman Diamond [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-10-28 16:10 Blockbusting news, results end Mudama, Eric
2003-10-28 18:30 ` bill davidsen
2003-10-27 17:50 Mudama, Eric
2003-10-26 18:39 Mudama, Eric
2003-10-27  9:45 ` Norman Diamond
2003-10-27 10:48   ` Krzysztof Halasa
2003-10-26  8:49 Norman Diamond
2003-10-26  9:22 ` Pavel Machek
2003-10-26 11:25   ` Norman Diamond
2003-10-27 20:58     ` jw schultz
2003-10-27 22:27       ` Andre Hedrick
2003-10-27 22:57         ` jw schultz
2003-10-28  2:03           ` jw schultz
2003-10-26 11:01 ` Hans Reiser
2003-10-26 12:59   ` Oleg Drokin
2003-10-26 12:05     ` Hans Reiser
2003-10-26 12:39       ` Oleg Drokin
2003-10-26 16:26         ` Hans Reiser
2003-10-26 17:13           ` Oleg Drokin
2003-10-26 18:20             ` Hans Reiser
2003-10-26 19:07               ` Oleg Drokin
2003-10-27 12:44                 ` Vitaly Fertman

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='058d01c39d47$39becbb0$f3ee4ca5@DIAMONDLX60' \
    --to=ndiamond@wta.att.ne.jp \
    --cc=eric_mudama@Maxtor.com \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).