Say, Jeff - Speaking of expensive, but interesting things we could do -
From the little I know of ZFS's checksum, it's NOT like the ECC checksum we use in memory in that it's not something we can use to determine which bit flipped in the event that there was a single bit flip in the data. (I could be completely wrong here... but...) What is the chance we could put a little more resilience into ZFS such that if we do get a checksum error, we systematically flip each bit in sequence and check the checksum to see if we could in fact proceed (including writing the data back correctly.). Or build into the checksum something analogous to ECC so we can choose to use NON-ZFS protected disks and paths, but still have single bit flip protection... Considering the pain that users of NON-ZFS protected systems suffer when there is minor corruption, it would be fantastic if we could attempt to work through the simple case of a single flipped bit for the user, and if we find that flipping said bit gets us to a consistent checksum, proceed. I know that on the default 128K block size, that's a lot of bits, and a lot of operations to arrive at an answer either way but if we could log an error, and spend the cycles to try to recover and proceed without user intervention, that would have to be a huge win for ZFS, even if the re-calculation took a few seconds. What do others on the list think? Do we have enough folks using ZFS on HDS / EMC / other hardware RAID(X) environments that might find this useful? Thoughts? And of course, sorry if we already do this... :) Nathan. Jeff Bonwick wrote: >> I thought RAIDZ would correct data errors automatically with the parity data. > > Right. However, if the data is corrupted while in memory (e.g. on a PC > with non-parity memory), there's nothing ZFS can do to detect that. > I mean, not even theoretically. The best we could do would be to > narrow the windows of vulnerability by recomputing the checksum > every time we accessed an in-memory object, which would be terribly > expensive. > > Jeff > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
