Linux ATA/IDE development
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Alexander Clausen <alex@gc-web.de>,
	linux-ide@vger.kernel.org
Subject: Re: 4k sector size and WD20EARS
Date: Thu, 08 Apr 2010 14:56:18 -0400	[thread overview]
Message-ID: <yq1d3y9wz71.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <alpine.DEB.1.10.1004081858560.21305@uplift.swm.pp.se> (Mikael Abrahamsson's message of "Thu, 8 Apr 2010 19:00:50 +0200 (CEST)")

>>>>> "Mikael" == Mikael Abrahamsson <swmike@swm.pp.se> writes:

>> We still haven't been given a comprehensive explanation.  "It breaks
>> something for someone" doesn't really give us much to work with...

Mikael> I don't really see what it is you're looking for when it comes
Mikael> to "more information"?

The physical block size is reported in IDENTIFY DEVICE word 106 which
hasn't been and isn't used for anything else.  So nothing should be
looking there unless it is 4KB sector-aware.

I've been testing a variety of drives with 4KB sectors for well over a
year.  All of them correctly reporting the physical block size.  The
only real problems I have found during testing have been missing
SCSI-ATA translation or incorrect alignment reporting (SCSI and ATA
express things differently).

It's bad enough that our I/O stack has to deal with hordes of USB ATA
bridge devices that are unintentionally broken.  But now we are talking
production disk drives that were intentionally neutered.  And we're not
being told why.

Obviously some of this might fall into NDA territory.  And that's fair
enough.  My gripe is that nothing has been done to substantiate the
issue.  A problem that apparently warranted blowing away years of
industry-wide standardization, implementation, and testing efforts.
That's no small thing in my book.

I also want to be assured that the real root cause gets fixed.  We
obviously want future drives to be both standards-compliant and accurate
in their reporting.

-- 
Martin K. Petersen	Oracle Linux Engineering

  reply	other threads:[~2010-04-08 18:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-08 14:20 4k sector size and WD20EARS Alexander Clausen
2010-04-08 16:02 ` Martin K. Petersen
2010-04-08 16:12   ` Mikael Abrahamsson
2010-04-08 16:33     ` Martin K. Petersen
2010-04-08 17:00       ` Mikael Abrahamsson
2010-04-08 18:56         ` Martin K. Petersen [this message]
2010-04-08 17:04   ` Alexander Clausen
2010-04-09  2:14     ` Martin K. Petersen
2010-04-12 12:34       ` Karel Zak

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=yq1d3y9wz71.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=alex@gc-web.de \
    --cc=linux-ide@vger.kernel.org \
    --cc=swmike@swm.pp.se \
    /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