Hi,
在 2022/10/11 23:15, Jaroslav Pulchart 写道:
Hello,
we disabled the wbt, issue is happening much sooner. The logs are attached
1/ "dmesg-20221011.log" form kernel messages
2/ "command.logs" from execution of
(cd /sys/kernel/debug/block/vdc && find . -type f -exec grep -aH . {} \;)
In the log, I found that many requests are stuck in the driver, for
example:
./hctx24/busy:00000000e790f153 {.op=WRITE, .cmd_flags=SYNC|NOMERGE,
.rq_flags=IO_STAT|STATS, .state=in_flight, .tag=234, .internal_tag=-1}
state=in_flight means the rq is issued to driver, and in_flight is set
in blk_mq_start_request().
Can you have a check when the problem triggered, the log in 'hctx*/busy'
stays the same so that we can be sure io is stuck in driver?
Thanks,
Kuai
Best regards,
Jaroslav Pulchart
čt 6. 10. 2022 v 18:57 odesílatel Bart Van Assche <bvanassche@xxxxxxx> napsal:
On 10/6/22 05:36, Jaroslav Pulchart wrote:
I apply the
echo 0 > /sys/block/vdc/queue/wbt_lat_usec
at the production servers. I expect it will disable wbt. Could you
please confirm that my expectation is correct?
Hi Jaroslav,
I have no experience with WBT. But what I found in the documentation seems
to confirm that the above command is sufficient to disable WBT:
What: /sys/block/<disk>/queue/wbt_lat_usec
Date: November 2016
Contact: linux-block@xxxxxxxxxxxxxxx
Description:
[RW] If the device is registered for writeback throttling, then
this file shows the target minimum read latency. If this latency
is exceeded in a given window of time (see wb_window_usec), then
the writeback throttling will start scaling back writes. Writing
a value of '0' to this file disables the feature. Writing a
value of '-1' to this file resets the value to the default
setting.
Best regards,
Bart.
