Michel Machado
Michel Machado
The symptoms you've described suggest you are dealing with a hardware issue. A **wild** hypothesis is that this power related. You can replace the power suppliers of these machines. Gatekeeper...
The flag `RTE_ETH_RSS_LEVEL_INNERMOST` would be an alternative solution for this problem if NICs supported it. However, this flag is virtually not supported in DPDK 23.11: ``` $ grep -r RTE_ETH_RSS_LEVEL_INNERMOST...
Hi @Yabgu, You can use `f3write` / `f3read` to check this drive. Since the drive must hold all the data to pass, it cannot escape this test. You can use...
HI @amreo, While it's not clear how to make `f3probe` report progress since it's not doing a well-delimited task, it should finish before one day, and it mostly finishes in...
If you don't want to wait for 70h, test only 30% of the drive using option `--end-at=307` of `f3write`. Once you have the report of `f3read`, you can try to...
Once you post the outputs of `f3write` and `f3read` on the drive, I can make an educated guess as to how the drive is fooling `f3probe`.
Duplicate of #196
What's your operating system, @axet? If I write a pull request for you to test, would you know how to apply the pull request to your local copy of F3,...
I've added code to the repository to report an error message when this problem comes up. It's an expected error, so I'll watch for what the error messages look like...
`fdatasync()` is called to satisfy a kernel demand to call `posix_fadvise()` next; see the manual for details. One could remove `fdatasync()` and `posix_fadvise()` from `f3read` since they are there to...