chihsuan commented on PR #10651: URL: https://github.com/apache/ozone/pull/10651#issuecomment-5242866798
Thanks @yandrey321 agreed on CRC32, that's the direction I'm going with. I'll update the PR. > In my view, Freon is primarily a stress testing tool meant to capture metrics like latency bottlenecks under load, while data integrity validation naturally belongs to E2E / integration testing. Thanks @chungen0126, and I do agree with that as a general principle: a benchmark shouldn't be doing work that distorts what it measures. Where I see it a bit differently is that Freon already carries a validator family alongside the pure generators. `dfsv` and `ockv` exist precisely to check data rather than to measure throughput, and this command is meant to sit there rather than next to `dfsg`. The generators stay untouched, so anyone after clean numbers still has `dfsg` and `ockrw`. On the coverage side, what this catches is a stale read, where a path gets overwritten, and a later read returns the older bytes. As far as I can tell, that isn't reachable from an integration test, since it only shows up under sustained concurrent load, and the client checksum wouldn't flag it either because the older version is still valid data with a matching checksum. Please do correct me if I'm missing something. To be clear, I'm just implementing what HDDS-14524 asks for here. @yandrey321 since you filed it with this spec, would you mind sharing whether validation is still what you'd like to see? And if the consensus is that Freon should stay validation-free, I'm happy to take that back to the Jira rather than settle it in this PR. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
