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" [1], 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? > Alas, > 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
