casper....@sun.com wrote:
I'm not saying that ZFS should consider doing this - doing a validation
for in-memory data is non-trivially expensive in performance terms, and
there's only so much you can do and still expect your machine to
survive. I mean, I've used the old NonStop stuff, and yes, you can
shoot them with a .45 and it likely will still run, but wacking them
with a bazooka still is guarantied to make them, well, Non-NonStop.
If we scrub the memory anyway, why not include the check of the ZFS
checksums which are already in memory?
OTOH, zfs gets a lot of mileage out of cheap hardware and we know what the
limitations are when you don't use ECC; the industry must start to require
that all chipsets support ECC.
Caspe
Reading the paper was interesting, as it highlighted all the places
where ZFS "skips" validation. There's a lot of places. In many ways,
fixing this would likely make ZFS similar to AppleTalk whose notorious
performance (relative to Ethernet) was caused by what many called the
"Are You Sure?" design. Double and Triple checking absolutely
everything has it's costs.
And, yes, we really should just force computer manufacturers to use ECC
in more places (not just RAM) - as densities and data volumes increase,
we are more likely to see errors, and without proper hardware checking,
we're really going out on a limb here to be able to trust what the
hardware says. And, let's face it - hardware error correction is /so/
much faster than doing it in software.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
Timezone: US/Pacific (GMT-0800)
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
