h a l f b a k e r yReplace "light" with "sausages" and this may work...
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Would that be nice to have a hard drive that act like a normal hard drive but that have redundancy inside. Instead of a raid system that you need to have all connected together with a motherboard that support it, etc., you just have a simple hard drive (well, look-a-like) with normal connection.
On
the data link, you can pass the status of the drive. With a simple (and I mean simple) software installed on the PC, you can monitor the drive. In case of a hazardous loss of power, physical shock, etc., the system will try to recover. I was thinking a 3-image system. When one byte is incorrect on one (like it's not the exact byte as the other 2 images), the byte will be replicated from the others. Some PM could be also added to a internal flash system. When some threshold are crossed (like a byte is obviously wrong too often), the software will notify the user that something is wrong with one of the image. Even if the system is running fine, there's a chance there's a physical problem with the disk.
In resume, it's a redundancy disk (the idea is existing) but with some internal intelligence and without the need of an additionnal hard drive.
I just bough a 80 Gigs for 75$ and I was: "Geez, that's @^# big, it would be nice to have a 30Gigs with redundancy instead!".
Redundant motor, head, dc converter (if any), circuitry, etc.
Waddayathink folks?
[link]
|
| |
I guess the big question is what modes of failure are likely to occur. If spindle motor failure is a risk, avoiding having that hit both drives would require using two motors. If head actuator failure, than redundant actuators and heads. If surface failure than redundant surfaces. If electronics failure than redundant electronics. |
|
| |
If one makes everything redundant, there's little advantage over having two separate drives. If there's only partial redundancy, then there's a cost saving in whichever part isn't redundant but no protection against that part's failure. |
|
| |
I like the idea of not having to configure a RAID
controller. You'd have one on the device already with
a fixed configuration. |
|
| |
To correct for media & head errors, it should be pretty simple to mirror data over the platters... could be done with just a new ROM. You'd halve(ish) sequential data transfer rate, but seek time would remain the same. |
|
| |
//You'd halve(ish) sequential data transfer rate// |
|
| |
What if the data were mirrored exactly (ie, down to
the physical location) on two or more identical
platters? Writing would happen simultaneously to all
platters, so would be as fast as usual. Reading would
normally be done from the primary platter but, in
the event of a broken file, the user could recover
the identical uncorrupted copy from another
platter. |
|
| |
Single sector read errors don't seem to be a very
common failure mode of modern hard drives, and
when you get one, it's generally a sign that the
drive is very near death. Drives generally fail due
to a faulty motor, bad electronics, head crash,
etc. All of these would still be a single point of
failure (I suppose theoretically in the event of a
head crash you might be able to recover data off
of a redundant platter, though). Realistically, to
provide the amount of protection that would be
equivalent to a RAID 1, you'd need enough
independent parts for two drives, which then of
course raises the obvious question—why not just
use two drives? They make RAID enclosures that
fit two 2.5" drives into a 3.5" form factor. |
|
| |
As an aside: An 80GB drive being considered huge?
How quaint that seems now that you can fit that
much data on an SD card for roughly the same
price, and I'm actually starting to find 2TB drives
to be a bit cramped... |
|
| |
[MB] That's what I meant: (I'm pretty sure that) HD data is spread over the platters vertically to begin with (with maybe a checksum platter side?), so rearranging them to mirror data inline wouldn't be much of a stretch. |
|
| |