Maybe I should've sticked to google (altough it wasn't to helpfull this
time) but
in this mailinglist there are a lot of knowledgeable people, so here's my
question:
for my data-recovery tool I like to read sectors from devices in RAW mode.
found how to do that for cd-rom, but ide/scsi/floppy still leave me
clueless.
Anyone out there who can tell me how to do all of this? (or give me hints on
where to find information that google hides from me)
I should clarify my question: I do not really mean reading RAW from
the device, but I want to read RAW like how its on this, without any
error-checking or anything.
Like the "CDROMREADRAW"-ioctl for CD-ROMs.
-----Oorspronkelijk bericht-----
Van: Rob Wilkens [mailto:[email protected]]
Verzonden: zaterdag 18 januari 2003 14:22
Aan: Folkert van Heusden
Onderwerp: Re: reading from devices in RAW mode
Just an idea, but try openning "/dev/fd0" for example -as the floppy-
directly, then "lseek"ing around and reading/writing as necessary.
Same should work for ide (open /dev/hda, or /dev/hdb, etc.) or scsi
(/dev/scd0, etc.).
As per where the useful information is stored on the disk, you'll have
to study filesystem code, and there I couldn't help you.
-Rob
On Sat, 2003-01-18 at 08:16, Folkert van Heusden wrote:
> Maybe I should've sticked to google (altough it wasn't to helpfull this
> time) but
> in this mailinglist there are a lot of knowledgeable people, so here's my
> question:
> for my data-recovery tool I like to read sectors from devices in RAW mode.
> found how to do that for cd-rom, but ide/scsi/floppy still leave me
> clueless.
> Anyone out there who can tell me how to do all of this? (or give me hints
on
> where to find information that google hides from me)
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> Yeah, I like it when people have a full mouth of how gotos are for lazy
> folks (not even bothering to grasp the context of the discussion) and
> how they could teach masterclass C courses, then ask a total newbie
> question.
Is it such a newby question? Your suggestion of using dd is totally NOT
what I meant: I want to read from devices with the devices ignoring their
CRC-checks and such. Like what the CDROMREADRAW ioctl does for CD-ROMs.
> Is it such a newby question? Your suggestion of using dd is totally NOT
> what I meant: I want to read from devices with the devices ignoring their
> CRC-checks and such. Like what the CDROMREADRAW ioctl does for CD-ROMs.
CD-ROMs, floppy disks, and hard disks work in completely different
ways:
All modern forms of storage use powerful error correction below the
sector level. Floppies are the exception here, they typically use MFM
encoding, which is relatively straightforward.
Audio Compact discs use powerful error correction anyway, but CD-ROMs
use some of the capacity which was previously used for audio data for
a second level of error correction, so there are two sector sizes,
(RAW, and COOKED). Reading RAW sectors, does not come close to
allowing you to read individual pits and flats on the disc, it just
lets you bypass the top level of error correction. The data is still
being error corrected by lower layers.
There is no floppy or hard disk equivillent to reading raw sectors
from CD-ROMs.
John.
> > Is it such a newby question? Your suggestion of using dd is totally NOT
> > what I meant: I want to read from devices with the devices ignoring
their
> > CRC-checks and such. Like what the CDROMREADRAW ioctl does for CD-ROMs.
> CD-ROMs, floppy disks, and hard disks work in completely different
> ways:
> All modern forms of storage use powerful error correction below the
> sector level. Floppies are the exception here, they typically use MFM
> encoding, which is relatively straightforward.
> Audio Compact discs use powerful error correction anyway, but CD-ROMs
> use some of the capacity which was previously used for audio data for
> a second level of error correction, so there are two sector sizes,
> (RAW, and COOKED). Reading RAW sectors, does not come close to
> allowing you to read individual pits and flats on the disc, it just
> lets you bypass the top level of error correction. The data is still
> being error corrected by lower layers.
oh, ok. But I will still get more data back then with reading through
the regular, say, /dev/hdc-device wouldn't I? As far as I know, read
will only give you data when no I/O error occured.
> There is no floppy or hard disk equivillent to reading raw sectors
> from CD-ROMs.
Really? Are you really sure about that?
Back in the old days, when I did assembly on my Atari ST, I would just
say to the controller "gimme this and that track, in RAW" and it
would do so. I thought that I could do that at least for floppy, not
sure about harddisk (RLL through ACSI interface).
> > There is no floppy or hard disk equivillent to reading raw sectors
> > from CD-ROMs.
>
> Really? Are you really sure about that?
Using a standard PC floppy controller - yes.
> Back in the old days, when I did assembly on my Atari ST, I would just
> say to the controller "gimme this and that track, in RAW" and it
> would do so.
Sure, you can do it on the Amiga as well, but not on a standard PC
floppy controller.
> I thought that I could do that at least for floppy, not sure about
> harddisk (RLL through ACSI interface).
Well, you can probably do it with ST-506 interface hard disk, because
the data that goes in to that is more or less directly fed from the
head-amp, which is partly why it was so sensitive to cable length.
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".
John.
> > I thought that I could do that at least for floppy, not sure about
> > harddisk (RLL through ACSI interface).
> Well, you can probably do it with ST-506 interface hard disk, because
> the data that goes in to that is more or less directly fed from the
> head-amp, which is partly why it was so sensitive to cable length.
Those were the times :-)
> 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)
> > 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.
"Folkert van Heusden" <[email protected]> wrote:
>
> Maybe I should've sticked to google (altough it wasn't to helpfull this
> time) but
> in this mailinglist there are a lot of knowledgeable people, so here's my
> question:
> for my data-recovery tool I like to read sectors from devices in RAW mode.
open("/dev/fd0", O_RDONLY|O_LARGEFILE|O_DIRECT);
maybe?
> I should clarify my question: I do not really mean reading RAW from
> the device, but I want to read RAW like how its on this, without any
> error-checking or anything.
Can't ide taskfile access be used for that?