> Apple code has no bugs that could send back bad data? Apple has access to hardware that does not experience bit rot? Apple's gear is not susceptible to firmware hacking?
'It' being checksums over data that they already know is checksummed by the F2L layer and they know the semantics of.
If you're hacking the firmware, you know that APFS is running on top of it, so you would just fix-up it's checksums too. APFS having checksums doesn't get you anything there either.
> The various old school SAN vendors have all sorts of control for storage controllers and disk firmware, and I've seen ZFS checksum errors appear on scrubs with them.
You have next to zero introspection into how those drives actually work, or where the semantics of their F2L breaks down the easiest (they hide all of that out of patent concerns). For instance do those drives work around a write ahead log primarily, or is it a more traditional block renaming tree? How many generations are there? All the BS counters in the world are next to meaningless without some base implementation knowledge that's missing.
'It' being checksums over data that they already know is checksummed by the F2L layer and they know the semantics of.
If you're hacking the firmware, you know that APFS is running on top of it, so you would just fix-up it's checksums too. APFS having checksums doesn't get you anything there either.
> The various old school SAN vendors have all sorts of control for storage controllers and disk firmware, and I've seen ZFS checksum errors appear on scrubs with them.
You have next to zero introspection into how those drives actually work, or where the semantics of their F2L breaks down the easiest (they hide all of that out of patent concerns). For instance do those drives work around a write ahead log primarily, or is it a more traditional block renaming tree? How many generations are there? All the BS counters in the world are next to meaningless without some base implementation knowledge that's missing.