On Sun, 2012-01-15 at 16:28 +0400, Jim Klimov wrote:
> 2012-01-14 18:36, Stefan Ring wrote:
> > Inspired by the paper "End-to-end Data Integrity for File Systems: A
> > ZFS Case Study" , I've been thinking if it is possible to devise a way,
> > in which a minimal in-memory data corruption would cause massive data
> > loss. I could imagine a scenario where an entire directory branch
> > drops off the tree structure, for example. Since I know too little
> > about ZFS's structure, I'm also asking myself if it is possible to
> > make old snapshots disappear via memory corruption or lose data blocks
> > to leakage (not containing data, but not marked as available).
I've never understood why these conclusions are considered so
interesting-- it's as though ZFS were analyzed as a system but the
conclusions weren't drawn systematically.
If you don't protect buffer integrity elsewhere on the system, what
would in be worth for ZFS to provide in-core integrity for its kernel
pages? The vast preponderance of consumers of ZFS data have to use
buffers outside of the ZFS kernel subsystem, leaving you with a trivial
added assurance in protecting against in-core corruption. Compare the
effort of doing that to the cost of using ECC, and there doesn't seem to
be anything like a compelling case for putting all that work into ZFS or
accepting the overhead that would result.
Put into a more reasonable context, there may still be something there,
but it looks very different than how the authors seemed to pitch it. Or
have I missed something?
> even though ECC chips and chipsets are cheap nowadays, not all
> architectures use them anyway (i.e. desktops, laptops, etc.),
> and the tagline of running ZFS for "reliable storage on consumer
> grade hardware" is poisoned by this fact.
Yes, you can get reliable and probably performant ZFS storage without
having to buy enterprise-class components. But you still have to treat
midrange or consumer components as differentiated on reliability and
performance if you want achieve those things meaningfully. ZFS is good,
but it's not magic.
zfs-discuss mailing list