From: davidsen@tmr.com (bill davidsen)
To: linux-kernel@vger.kernel.org
Subject: Re: Blockbusting news, results end
Date: 28 Oct 2003 18:30:43 GMT [thread overview]
Message-ID: <bnmckj$r90$1@gatekeeper.tmr.com> (raw)
In-Reply-To: 785F348679A4D5119A0C009027DE33C105CDB3CA@mcoexc04.mlm.maxtor.com
In article <785F348679A4D5119A0C009027DE33C105CDB3CA@mcoexc04.mlm.maxtor.com>,
Mudama, Eric <eric_mudama@Maxtor.com> wrote:
|
|
| > -----Original Message-----
| > From: Norman Diamond
| > 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.
Given that we did that back in the CP/M days (late 70's) on floppy, and
with MFM, RLL and finally SCSI drives in the 70's, I would hope that
current drives use large sectors since the drive now has local cache
and doesn't need a fancy driver to do the caching!
| > 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.
Given that the IRG is fixed size regardless of sector size, I certainly
hope I misread what you say or you are incorrect. The difference
between 512B and 4KB sectors should be about 20-40% added capacity per
track (seven IRG sizes). I would expect large sectors would be
standard.
We used to diddle interleave when formatting as well, until we put full
track caching in the device driver.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
next prev parent reply other threads:[~2003-10-28 18:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-28 16:10 Blockbusting news, results end Mudama, Eric
2003-10-28 18:30 ` bill davidsen [this message]
-- 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='bnmckj$r90$1@gatekeeper.tmr.com' \
--to=davidsen@tmr.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.