This is a bit weird: I just wrote the following response to a dd-b post that now seems to have disappeared from the thread. Just in case that's a temporary aberration, I'll submit it anyway as a new post.
> can you guess? wrote: > > Ah - thanks to both of you. My own knowledge of > video format internals is so limited that I assumed > most people here would be at least equally familiar > with the notion that a flipped bit or two in a video > would hardly qualify as any kind of disaster (or > often even as being noticeable, unless one were > searching for it, in the case of commercial-quality > video). > > > > But also, you're thinking like a consumer, Well, yes - since that's the context of my comment to which you originally responded. Did you manage to miss that, even after I repeated it above in the post to which you're responding *this* time? not like > an archivist. A bit > lost in an achival video *is* a disaster, or at least > a serious degradation. Or not, unless you're really, really obsessive-compulsive about it - certainly *far* beyond the point of being reasonably characterized as a 'consumer'. ... And since the CERN study seems > to suggest that the vast majority of errors likely to > be encountered at this level of incidence (and which > could be caught by ZFS) are *detectable* errors, > they'll (in the unlikely event that you encounter > them at all) typically only result in requiring use > of a RAID (or backup) copy (surely > > one wouldn't be entrusting data of any real value > to a single disk). > > > > They'll only be detected when the files are *read*; > ZFS has the "scrub" > concept, but most RAID systems don't, Perhaps you're just not very familiar with other systems, David. For example, see http://gentoo-wiki.com/HOWTO_Gentoo_Install_on_Software_RAID#Data_Scrubbing, where it tells you how to run a software RAID scrub manually (or presumably in a cron job if it can't be configured to be more automatic). Or a variety of Adaptec RAID cards which support two different forms of scanning/fixup which presumably could also be scheduled externally if an internal scheduling mechanism is not included). I seriously doubt that these are the only such facilities out there: they're just ones I happen to be able to cite with minimal effort. ... > > So I see no reason to change my suggestion that > consumers just won't notice the level of increased > reliability that ZFS offers in this area: not only > would the difference be nearly invisible even if the > systems they ran on were otherwise perfect, but in > the real world consumers have other reliability > issues to worry about that occur multiple orders of > magnitude more frequently than the kinds that ZFS > protects against. > > > > And yet I know many people who have lost data in ways > that ZFS would > have prevented. Specifics would be helpful here. How many? Can they reasonably be characterized as consumers (I'll remind you once more: *that's* the subject to which your comments purport to be responding)? Can the data loss reasonably be characterized as significant (to 'consumers')? Were the causes hardware problems that could reasonably have been avoided ('bad cables' might translate to 'improperly inserted, overly long, or severely kinked cables', for example - and such a poorly-constructed system will tend to have other problems that ZFS cannot address)? - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
