From: Grant Grundler <grundler@google.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: "Wilcox, Matthew R" <matthew.r.wilcox@intel.com>,
Tejun Heo <tj@kernel.org>, Linux IDE <linux-ide@vger.kernel.org>,
Gwendal Grignou <gwendal@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] 2.6.35 libata support for > 512 byte sectors (e.g. 4K Native)
Date: Mon, 16 Aug 2010 13:24:09 -0700 [thread overview]
Message-ID: <AANLkTi=R4GQGVE5AvU9hdWXdtqZzaOswrGQA+cPgO58W@mail.gmail.com> (raw)
In-Reply-To: <4C699455.6020200@pobox.com>
On Mon, Aug 16, 2010 at 12:41 PM, Jeff Garzik <jgarzik@pobox.com> wrote:
...
> The main question is whether the size of a DRQ block changes, when LBA
> logical size changes?
Don't we already know that depends on the ATA command?
> I need to review the ATA8 specs in this area, but I
> would think some interfaces that return 512-byte pages for things like SMART
> info would be unchanged. How do the drives behave for PIO-Data-{In,Out}
> commands that are not reading/writing user data, but rather drive metadata?
SMART Info/Logs are meta data and as you noted unchanged.
Two other meta-data PIO commands I can think of:
o FW update: I'm not going to risk bricking this drive to find that out.
o Vendor specific selftest/diagnostic commands (I don't know if any
exist - just a guess)
If someone from Hitachi cares to respond publicly regarding the
behavior of this "Engineering Sample", that would be appreciated and
helpful. But feedback from any other vendor would be welcome/useful
also.
I suspect legacy tools might be needed to update firmware and those
might continue to function if DRQ block size is still 512 byte. I'd
like to leave this hardcoded to ATA_SECT_SIZE until someone can
demonstrate a need to change it. Ok?
thanks,
grant
next prev parent reply other threads:[~2010-08-16 20:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-15 0:00 [PATCH] 2.6.35 libata support for > 512 byte sectors (e.g. 4K Native) Grant Grundler
2010-08-15 4:37 ` Wilcox, Matthew R
2010-08-16 19:17 ` Grant Grundler
2010-08-16 19:41 ` Jeff Garzik
2010-08-16 20:24 ` Grant Grundler [this message]
2010-08-17 15:22 ` Tejun Heo
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='AANLkTi=R4GQGVE5AvU9hdWXdtqZzaOswrGQA+cPgO58W@mail.gmail.com' \
--to=grundler@google.com \
--cc=gwendal@google.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.r.wilcox@intel.com \
--cc=tj@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).