On 9/18/06, Richard Elling - PAE <[EMAIL PROTECTED]> wrote:
[appologies for being away from my data last week]David Dyer-Bennet wrote: > The more I look at it the more I think that a second copy on the same > disk doesn't protect against very much real-world risk. Am I wrong > here? Are partial(small) disk corruptions more common than I think? > I don't have a good statistical view of disk failures. This question was asked many times in this thread. IMHO, it is the single biggest reason we should implement ditto blocks for data. We did a study of disk failures in an enterprise RAID array a few years ago. One failure mode stands heads and shoulders above the others: non-recoverable reads. A short summary: 2,919 total errors reported 1,926 (66.0%) operations succeeded (eg. write failed, auto reallocated) 961 (32.9%) unrecovered errors (of all types) 32 (1.1%) other (eg. device not ready) 707 (24.2%) non-recoverable reads In other words, non-recoverable reads represent 73.6% of the non- recoverable failures that occur, including complete drive failures.
I don't see anything addressing complete drive failures vs. block failures here anywhere. Is there some way to read something about that out of this data? I'm thinking the "operations succeeded" also occurs read errors recovered by retries and such, as well as the write failure cited as an example? I guess I can conclude that the 66% for errors successfully recovered means that a lot of errors are not, in fact, entire-drive failures. So that's good (for ditto-data). So a maximum of 34% are whole-drive failures (and in reality I'm sure far lower). Anyway, facts on actual failures in the real world are *definitely* the useful way to conduct this discussion! [snip]
While it is true that I could slice my disk up into multiple vdevs and mirror them, I'd much rather set a policy at a finer grainularity: my files are more important than most of the other, mostly read-only and easily reconstructed, files on my system.
I definitely like the idea of setting policy at a finer granularity; I really want it to be at the file level, even per-directory doesn't fit reality very well in my view.
When ditto blocks for metadata was introduced, I took a look at the code and was pleasantly suprised. The code does an admirable job of ensuring spatial diversity in the face of multiple policies, even in the single disk case. IMHO, this is the right way to implement this and allows you to mix policies with ease.
That's very good to hear. -- David Dyer-Bennet, <mailto:[EMAIL PROTECTED]>, <http://www.dd-b.net/dd-b/> RKBA: <http://www.dd-b.net/carry/> Pics: <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
