Re: If you were developing a database in Forth...

John Passaniti <john.passaniti@xxxxxxxxx> wrote:
Jonah Thomas <jethom...@xxxxxxxxx> wrote:

Thank you. So while I wasn't looking this whole topic became
irrelevant. I like that.

It's not irrelevant. For disks, the problem just shifts to the
controller, and last I checked, that's an embedded system (so the
question of how to handle back blocks on spinning storage media is
still relevant, just not necessarily relevant to the application level
as it once was). Now the OS or application has the responsibility of
querying the drive's controller to get a sense of the health of the
disk, since presumably one would like to know the drive is going to
fail before it actually does.

It doesn't look like a database issue to me. You budget regular
replacement of hard disks, enough shorter than the estimated MTBF to
balance failures versus costs. You keep spare disks on hand in case of
an unexpected failure. You query the drive controller weekly? daily?
hourly? but it isn't a database issue. The database issue is you likely
don't want to consider an update to be complete until you've verified
that it's actually been copied onto nonvolatile mass storage.

It's also not irrelevant because there is more than just hard drives
being used as storage. In particular flash memory by design often has
some amount of defects (and grows defects with each erase/write
cycle). Differences in the technologies used by flash can either
(like hard drives) hide the details behind a controller or put it
right in your face.

If you choose to keep your database on media that puts the failure
details right in your face then your database software has to deal with
those details. Your choice, if you get to choose the media.

I've never done much with databases. I remember reading that a
fundamental principle is to have each piece of data stored in precisely
one place and always refer to that location rather than allow more than
one copy be stored. My natural thought is that if you want not to lose
data, don't consider a change to be verified until you've checked that
it's correctly stored in three different places. Then if one of them
fails you have two backups. But I guess if you record the verification
in three different places and those might not all go through, then
there's room for an infinite regress....

"A man with one clock knows what time it is. A man with two clocks is
never sure."
.

Relevant Pages

  • Re: 6.2 not compatible with new sata drives ?!
    ... Some combinations of controller and drive do not play well ... I assume that the new failing disks are ... If your controller works well with your Samsung drives, ... Decided to try my origonal 6.2amd64 iso again, ...
    (freebsd-questions)
  • Re: Anyone seen this before?
    ... with an Adaptec 2110S RAID controller and a pair of disks. ... drive and home brewed cpio backup with a DVD writer and Microlite ... When testing the RE2 disaster recovery CD boot ...
    (comp.unix.sco.misc)
  • SUMMARY: V440 small DATABASE SERVER
    ... apprehensive about how few disks you're using. ... PICK variant database, so your mileage with my "advice" may vary. ... the App is tuned to not do crazy IO (queries tuned), ... We had a small extranet server running a fairly classic "3-tier" client ...
    (SunManagers)
  • Re: %MOUNT-W-INCONSIZE
    ... > attached to the big multi-function connector on the back of the machine. ... Where a DSSI disk has its own built-in controller that lets you set ALLCLASS ... IIRC it also allows you to assign device names to the disks, ...
    (comp.os.vms)
  • SA3200 Disk array controller in PC (was: 5300 Disk array controller in PC)
    ... > during the power-up of the PC and the card on its turn sees the disks. ... the physical drives to a logical array. ... First, you have to go into the controllers BIOS setup (ACU, Array ... Windows requires drivers for the controller. ...
    (comp.sys.hp.hardware)