linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: Greg Freemyer <greg.freemyer@norcrossgroup.com>
Cc: Ric Wheeler <rwheeler@redhat.com>,
	linux-raid <linux-raid@vger.kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Dongjun Shin <djshin90@gmail.com>,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: SSD data reliable vs. unreliable [Was: Re: Data Recovery from SSDs - Impact of trim?]
Date: Mon, 26 Jan 2009 13:21:14 -0500	[thread overview]
Message-ID: <497DFF1A.2050401@rtr.ca> (raw)
In-Reply-To: <87f94c370901261009w431156fbx4d2b20638dc5097c@mail.gmail.com>

Greg Freemyer wrote:
>
> Just so I know and before I try to find the right way to comment to
> the T13 and T10 committees:
> 
> What is the negative of adding a ATA/SCSI command to allow the storage
> device to be interrogated to see what sectors/blocks/erase-units are
> in a mapped vs. unmapped state?
> 
> For T13 (ATA), it would actually be a tri-state flag I gather:
> 
>   Mapped - last data written available
>   unmapped - no data values assigned
>   unmapped - deterministic data values
> 
> Surely the storage device has to be keeping this data internally.  Why
> not expose it?
..

That's a good approach.  One problem on the drive end, is that they
may not be maintain central lists of these.  Rather, it might be stored
as local flags in each affected sector.

So any attempt to query "all" is probably not feasible,
but it should be simple enough to "query one" sector at a time
for that info.  If one wants them all, the just loop over
the entire device doing the "query one" for each sector.

Another drawback to the "query all", is the size of data (the list)
returned is unknown in advance.  We generally don't have commands
that work like that.

Cheers

  reply	other threads:[~2009-01-26 18:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 23:53 SSD data reliable vs. unreliable [Was: Re: Data Recovery from SSDs - Impact of trim?] Greg Freemyer
2009-01-23 20:40 ` Ric Wheeler
2009-01-23 22:24   ` James Bottomley
2009-01-23 23:26     ` Greg Freemyer
2009-01-23 23:35       ` Ric Wheeler
     [not found]         ` <7fce22690901260659u30ffd634m3fb7f75102141ee9@mail.gmail.com>
2009-01-26 16:22           ` Ric Wheeler
2009-01-26 17:34             ` Greg Freemyer
2009-01-26 17:46               ` Ric Wheeler
2009-01-26 17:47               ` James Bottomley
2009-01-27  5:16                 ` Neil Brown
2009-01-27 10:49                   ` John Robinson
2009-01-28 20:11                     ` Bill Davidsen
     [not found]                       ` <7fce22690901281556h67fb353dp879f88e6c2a76eaf@mail.gmail.com>
2009-01-29  1:49                         ` John Robinson
2009-01-27 11:23                   ` Ric Wheeler
2009-01-28 20:28                     ` Bill Davidsen
2009-01-27 14:48                   ` James Bottomley
2009-01-27 14:54                     ` Ric Wheeler
2009-01-26 17:51               ` Mark Lord
2009-01-26 18:09                 ` Greg Freemyer
2009-01-26 18:21                   ` Mark Lord [this message]
2009-01-29 14:07                     ` Dongjun Shin
2009-01-29 15:46                       ` Mark Lord
2009-01-29 16:27                         ` Greg Freemyer
2009-01-30 15:43                           ` Bill Davidsen

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=497DFF1A.2050401@rtr.ca \
    --to=liml@rtr.ca \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=djshin90@gmail.com \
    --cc=greg.freemyer@norcrossgroup.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    /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).