public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Bradford <john@grabjohn.com>
To: folkert@vanheusden.com (Folkert van Heusden)
Cc: linux-kernel@vger.kernel.org
Subject: Re: reading from devices in RAW mode
Date: Sat, 18 Jan 2003 17:33:37 +0000 (GMT)	[thread overview]
Message-ID: <200301181733.h0IHXbkZ001932@darkstar.example.net> (raw)
In-Reply-To: <004d01c2bf14$54099340$3640a8c0@boemboem> from "Folkert van Heusden" at Jan 18, 2003 06:09:13 PM

> > The closest you could probably get with any modern device would be
> > "read sector foo, and return data even if ECC appears to have
> > failed".
> 
> And that's exactly what I want!
> (for the situations where the bad data starts, say, halfway the sector)

You'd have to ask the IDE and SCSI subsystem people for programming
information about how to do that for disks.

The problem is that as far as I know, if the ECC doesn't work, you
won't end up getting back back more or less intact data, with just a
flipped bit here and there.

I'm not sure exactly how it works, but the basic theory is something
along these lines:

Suppose you are storing 5 data bits using 10 actual bits on disk.

Typically, you might expect a read to read to return 8 bits accurately
and 2 bits inaccurately.  That's enough to re-construct the data.
When 6 bits are read inaccurately, an un-correctable error occurs.
Retrying the read might succeed, because only 4 bits might be read
inaccurately the second time.

Although reading without using error correction will allow you to
access the unreadable data, is quite likely to return some of the 5
data bits incorrectly, which could have been corrected, incorrectly.

I hope that explaination is of some use - maybe somebody else can
improve it.

John.

  reply	other threads:[~2003-01-18 17:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030118132315.GF19381@louise.pinerecords.com>
2003-01-18 14:00 ` reading from devices in RAW mode Folkert van Heusden
2003-01-18 14:30   ` John Bradford
2003-01-18 16:03     ` Folkert van Heusden
2003-01-18 16:15       ` John Bradford
2003-01-18 17:09         ` Folkert van Heusden
2003-01-18 17:33           ` John Bradford [this message]
2003-01-19 21:03 Arnaud Boulan
     [not found] <1042896128.1157.4.camel@RobsPC.RobertWilkens.com>
2003-01-18 13:58 ` Folkert van Heusden
  -- strict thread matches above, loose matches on Subject: below --
2003-01-18 13:16 Folkert van Heusden
2003-01-18 18:50 ` Andrew Morton

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=200301181733.h0IHXbkZ001932@darkstar.example.net \
    --to=john@grabjohn.com \
    --cc=folkert@vanheusden.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox