On 2023/8/17 09:12, Jens Axboe wrote:
On 8/16/23 7:05 PM, Qu Wenruo wrote:
On 2023/8/17 06:28, Jens Axboe wrote:
[...]
2) What's the .config you are using?
Pretty common config, no heavy debug options (KASAN etc).
Please just send the .config, I'd rather not have to guess. Things like
preempt etc may make a difference in reproducing this.
Sure, please see the attached config.gz
Thanks
And just to be sure, this is not mixing dio and buffered, right?
I'd say it's mixing, there are dwrite() and writev() for the same file,
but at least not overlapping using this particular seed, nor they are
concurrent (all inside the same process sequentially).
But considering if only uring_write is disabled, then no more reproduce,
thus there must be some untested btrfs path triggered by uring_write.
That would be one conclusion, another would be that timing is just
different and that triggers and issue. Or it could of course be a bug in
io_uring, perhaps a short write that gets retried or something like
that. I've run the tests for hours here and don't hit anything, I've
pulled in the for-next branch for btrfs and see if that'll make a
difference. I'll check your .config too.
Just to mention, the problem itself was pretty hard to hit before if
using any debug kernel configs.
Not sure why but later I switched both my CPUs (from a desktop i7-13700K
but with limited 160W power, to a laptop 7940HS), dropping all heavy
debug kernel configs, then it's 100% reproducible here.
So I guess a faster CPU is also one factor?
Might not be a bad idea to have the writes contain known data, and when
you hit the failure to verify the csum, dump the data where the csum
says it's wrong and figure out at what offset, what content, etc it is?
If that can get correlated to the log of what happened, that might shed
some light on this.
Thanks for the advice, would definitely try this method, would keep you
updated when I found something valuable.
Thanks,
Qu
