Workflow [PR], commit [2153f08]

Summary: ✅

TIL that strace can inject. I always used it to just trace 🙄
I ran in local the tests with your changes and it took 20m47s. master takes 14m57s

This PR

[2025-12-19 11:48:31] test_storage_rabbitmq/test.py::test_rabbitmq_select[0]
[2025-12-19 12:07:31] [gw0] [ 34%] PASSED test_merge_tree_s3/test.py::test_simple_insert_select[0-17-node]

Latest PR that brings back RabbitMQ

[2025-12-18 21:25:27] test_storage_rabbitmq/test.py::test_rabbitmq_select[0]
[2025-12-18 21:39:57] [gw0] [ 34%] PASSED test_merge_tree_s3/test.py::test_simple_insert_select[0-17-node]

So, it seems the overhead of injecting with strace is bigger than the gain of mocking fsync/fdatasync

I ran in local the tests with your changes and it took 20m47s. master takes 14m57s

Thanks for checking it!

Interesting though, I would expect that the overhead should be almost zero, since it should replace only fsync/fdatasync, and injecting return value should be fast, I've also tested it with MinIO locally and although it does not help (due to O_DSYNC usage in MinIO) it did not make things slower

Will check later

I ran in local the tests with your changes and it took 20m47s. master takes 14m57s

Maybe it is a margin of error for rabbitmq?
Also do you have SSD/NVME locally?

But I don't see any improvements on CI either, will close for now.

Also do you have SSD/NVME locally?

Yes, it was on the AWS dev machine with NVME disks

But I don't see any improvements on CI either, will close for now.

Yeah, that was the last part of my comment.

This PR 19min, PR that brough rabbitmq back to life 14:30min.

We're probably missing something, or just using strace to inject even those two mock syscalls is not as negligible as it looks like. Very nice idea to test this, in any case.