Hi [at the risk of straying on-topic...]
On misc@openbsd.org you said: > Dear list, especially Greg and Mickey, > > I've updated the working copy of the CCD Mirroring HOWTO. In particular, > I've split off the comparison to software RAID into a separate section > and clarified that ccd does not do automatic recovery, and I've > rewritten the section on labeling to state that the c partition must be > set to unused, and normal partitions created instead. So one thing that's still missing is a big, bold line at the top that says: CCD Mirroring will eventually eat your data and you shouldn't use it!! Allow me to re-phrase/expand on the concerns I expressed earlier: 1) Let's say you build ccd0 out of wd0e and wd1e. Further suppose that wd0e suffers a failure for a given sector, and that you attempt to read that sector. What mechanism in ccd detects the read error, and returns the correct data from wd1e instead? Or will the read error be simply returned to an upper-level, in which case you get an IO error? 2) Let's say you're happily running some application that is writing data, and the system dies (power outage, panic, cat steps on power bar, whatever). When it was writing your document, it managed to get everything written to wd0e, but didn't manage to write one block to wd1e. (That one block might be file data associated with your document, or, say, indirect block pointers which describe where most of the document lives on disk.) You boot the system, and fsck on the ccd happily reads bits from wd0e, and declares everything as "fine". You don't touch the document for a week (so the errant block on wd1e is never corrected), and during that time, wd0e suffers a complete failure. You now use "dd" to "recover" from wd1e, and then later wonder a) why fsck found errors, and/or b) why your document is corrupt, and/or c) where 90% of your document went to!!!! What mechanism in ccd guarantees (as reasonably as possible) that the mirror components are in-sync after a system failure? If they are not kept in sync, then it's not really mirroring, and you *WILL* eventually lose data. If there is not a solution to this, then CCD Mirroring should *not* be used. To promote the use of CCD Mirroring without noting the above major problems is a disservice to the novice who is likely not aware of the above failure modes. To me, until the above have satisfactory answers, the only thing the CCD Mirroring HOWTO (and the ccd(4)/ ccdconfig(8) man-pages!) should recommend is: Don't use CCD Mirroring -- at best, it provides a false sense of security. At worst, it will eat your data. If you need mirroring functionality, use RAIDframe. Really. RAIDframe works, and it doesn't suffer from the serious problems noted above. (<mini-rant> Oh... someone else commented: "The full base system has been audited." This CCD Mirroring stuff is a case-in-point as to why I don't believe that "everything has been auditing" line... Let's pretend that the above "document" was a packet filter configuration (or some other security-configuration file). And let's further pretend that you don't touch that file for, say, some number of months, happy in your oblivion that it's been saved correctly on both wd0e and wd1e. And then wd0e dies. After you do the "dd" to "recover" you now get an *OLD* configuration, instead of a new one, perhaps *SILENTLY* resulting in a different security policy than what you intended. This is either evidence that a) the full base system has *NOT* been completely audited as implied, or b) the audit was not thorough enough to catch this. If OpenBSD is "all about security", I fail to see how CCD Mirroring still exists in its current form, especially without any warnings as to what it can do to your data and/or the security/integrity of the system! </mini-rant>) I'll go crawl back under my rock now, since apparently I'm taking data integrity too seriously... Thanks for reading this far. Later... Greg Oster
