On Fri, 2017-05-26 at 16:38 +0200, Hannes Reinecke wrote:
> Hmm. I wonder if this is going to work as intended; 'busy' might be
> changing rapidly, so the busy_iter might be giving us unintended results.
> Have you checked?
Hello Hannes,
The intention is that this attribute is used by developers to figure out which
requests got stuck if one or more requests got stuck. Querying this attribute a
few times should help to see whether the requests shown are requests that
complete quickly or whether these are requests that got stuck. The output I
collected while testing this debugfs attribute looks fine to me:
# while true; do (cd /sys/kernel/debug/block && for f in */*/busy; do [ -e $f ] && grep -aH '' $f; done); done
[ ... ]
sde/hctx0/busy:ffff880267dcba00 {.op=WRITE, .cmd_flags=FAILFAST_TRANSPORT|SYNC|META|PRIO|NOMERGE, .rq_flags=MQ_INFLIGHT|DONTPREP|IO_STAT|STATS, .atomic_flags=STARTED, .tag=19, .internal_tag=-1,
.cmd=Write(10) 2a 00 00 07 92 38 00 00 08 00}
sde/hctx0/busy:ffff880267dcd140 {.op=WRITE, .cmd_flags=FAILFAST_TRANSPORT|SYNC|META|PRIO|NOMERGE, .rq_flags=MQ_INFLIGHT|DONTPREP|IO_STAT|STATS, .atomic_flags=STARTED, .tag=20, .internal_tag=-1,
.cmd=Write(10) 2a 00 00 07 92 80 00 00 08 00}
[ ... ]
sr0/hctx0/busy:ffff88046797d140 {.op=SCSI_IN, .cmd_flags=, .rq_flags=DONTPREP|PREEMPT|COPY_USER|QUIET|IO_STAT|STATS, .atomic_flags=STARTED, .tag=20, .internal_tag=-1, .cmd=Get event status
notification 4a 01 00 00 10 00 00 00 08 00}
[ ... ]
Bart.
