Thanks for the detailed reply, Robert. A significant part of it seems to be suggesting that high-end array hardware from multiple vendors may be *introducing* error sources that studies like CERN's (and Google's, and CMU's) never encountered (based, as they were, on low-end hardware).
If so, then at least a major part of your improved experience is not due to using ZFS per se but to getting rid of the high-end equipment and using more reliable commodity parts: a remarkable thought - I wonder if anyone has ever done that kind of a study. A quick Google of ext3 fsck did not yield obvious examples of why people needed to run fsck on ext3, though it did remind me that by default ext3 runs fsck just for the hell of it every N (20?) mounts - could that have been part of what you were seeing? There are two problems with over-hyping a product: it gives competitors something legitimate to refute, and it leaves the impression that the product has to be over-sold because it doesn't have enough *real* merits to stand on. Well, for people like me there's a third problem: we just don't like spin. When a product has legitimate strengths that set it out out from the pack, it seems a shame to over-sell it the same way that a mediocre product is sold and waste the opportunity to take the high ground that it actually does own. I corrected your misunderstanding about WAFL's separate checksums in my October 26th response to you in http://storagemojo.com/2007/10/25/sun-fires-back-at-netapp/ - though in that response I made a reference to something that I seem to have said somewhere (I have no idea where) other than in that thread. In any event, one NetApp paper detailing their use is 3356.pdf (first hit if you Google "Introduction to Data ONTAP 7G") - search for 'checksum' and read about block and zone checksums in locations separate from the data that they protect. As just acknowledged above, I occasionally recall something incorrectly. I now believe that the mechanisms described there were put in place more to allow use of disks with standard 512-byte sector sizes than specifically to separate the checksums from the data, and that while thus separating the checksums may achieve a result similar to ZFS's in-parent checksums the quote that you provided may indicate the primary mechanism that WAFL uses to validate its data: whether the 'checksums' reside with the data or elsewhere, I now remember reading (I found the note that I made years ago, but it didn't provide a specific reference and I just spent an hour searching NetApp's Web site for it without success) that the in-block (or near-to-block) 'checksums' include not only file identity and offset information but a block generation number (I think this is what the author meant by the 'identity' of the block) that increments each time the block is updated, and that this generation nu mber is kept in the metadata block that points to the file block, thus allowing the metadata block to verify with a high degree of certainty that the target block is indeed not only the right file block, containing the right data, but the right *version* of that block. As I said, thanks (again) for the detailed response, - bill This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
