linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mudama, Eric" <eric_mudama@Maxtor.com>
To: "'Norman Diamond'" <ndiamond@wta.att.ne.jp>,
	linux-kernel@vger.kernel.org, jw@pegasys.ws
Subject: RE: Blockbusting news, results end
Date: Tue, 28 Oct 2003 09:10:00 -0700	[thread overview]
Message-ID: <785F348679A4D5119A0C009027DE33C105CDB3CA@mcoexc04.mlm.maxtor.com> (raw)



> -----Original Message-----
> From: Norman Diamond
> 
> 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.

I don't think your friends know what they're talking about.

Disk drives that use anything resembling the "standard" channel technology
have 2 physical sector types: servo sectors and data sectors.  Servo sectors
are designed to give the servo system a constant sample rate at any radius,
therefore they're constant in time, but get physically closer as you get
closer to the ID of the drive.  Data sectors are a fixed size, to hold a
certain number of user bytes of data, and they can be split, etc, as needed
to fit them nicely on the drive.

A modern disk has "a few" data sectors per servo sector at the OD (think
3-4.5), and "a few less" at the ID of the drive. (think 1.5-2).

The 1MB number can't possibly be a servo sector, since a modern drive
transfers ~50-70MB/sec, which would imply that their servo system is holding
postion within microns, only sampling 50-70 times/second.

I don't think any modern drive can hold 1MB on a single track, I know what
our current limit is, and we're not there yet.  (Anyone can figure this out
by looking at sequential read throughput per revolution)

That would mean that to be 1MB for a data sector, or anywhere close, they're
spanning a single data cylinder across tracks.  This doesn't make sense
either.

What I think is possible, but still unlikely, is that their defect
management scheme might not be capable of handling single-block defects.
However, disk drives have had that ability for tens of years, I can't see
how they could possibly sell a drive that way.

There's also a chance that in doing the larger write, you "cleaned up" a
poorly written adjacent track or ratty servo burst, which could account for
it working now.

Other than the track size and the DRAM buffer size, I can't think of
anything else offhand in a disk drive that is "about 1MB"

The insides of these things are near voodoo-magic...

> 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.

We measure these gaps in nanoseconds.  They're not that huge.  But yes,
moving to a larger standard sector size would get you a significantly larger
disk drive built from the same parts.

> I'm sure the physical sectors are not 512B.

I'm sure you're wrong.

I'd imagine that since Seagate and WD and Maxtor are constantly duking it
out to release the next generation of capacity, and we all wind up producing
nearly-identical products when all is said and done, that they're using 512B
data sectors also.

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

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-28 16:10 Mudama, Eric [this message]
2003-10-28 18:30 ` Blockbusting news, results end bill davidsen
  -- strict thread matches above, loose matches on Subject: below --
2003-10-28 11:31 Norman Diamond
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=785F348679A4D5119A0C009027DE33C105CDB3CA@mcoexc04.mlm.maxtor.com \
    --to=eric_mudama@maxtor.com \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndiamond@wta.att.ne.jp \
    /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).