On Tue, Sep 30, 2008 at 5:19 PM, Erik Trimble <[EMAIL PROTECTED]> wrote:
> > To make Will's argument more succinct (<wink>), with a NetApp, undetectable > (by the NetApp) errors can be introduced at the HBA and transport layer (FC > Switch, slightly damage cable) levels. ZFS will detect such errors, and > fix them (if properly configured). NetApp has no such ability. > > Also, I'm not sure that a NetApp (or EMC) has the ability to find bit-rot. > That is, they can determine if a block is written correctly, but I don't > know if they keep the block checksum around permanently, and, how redundant > that stored block checksum is. If they don't permanently write the block > checksum somewhere, then the NetApp has no way to determine if a READ block > is OK, and hasn't suffered from bit-rot (aka disk block failure). And, if > it's not either multiply stored, then they have the potential to lose the > ability to do READ verification. Neither are problems of ZFS. > > > In many of my production environments, I've got at least 2 different FC > switches between my hosts and disks. And, with longer cables, comes more of > the chance that something gets bent a bit too much. Finally, HBAs are not > the most reliable things I've seen (sadly). > > > * NetApp's block-appended checksum approach appears similar but is in fact much stronger. Like many arrays, NetApp formats its drives with 520-byte sectors. It then groups them into 8-sector blocks: 4K of data (the WAFL filesystem blocksize) and 64 bytes of checksum. When WAFL reads a block it compares the checksum to the data just like an array would, but there's a key difference: it does this comparison after the data has made it through the I/O path, so it validates that the block made the journey from platter to memory without damage in transit. * **
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
