On Mon, Nov 25, 2019 at 07:51:33PM +0100, Andrea Vai wrote: > Il giorno lun, 25/11/2019 alle 23.15 +0800, Ming Lei ha scritto: > > On Mon, Nov 25, 2019 at 03:58:34PM +0100, Andrea Vai wrote: > > > > [...] > > > > > What to try next? > > > > 1) cat /sys/kernel/debug/block/$DISK/hctx0/flags > result: > > alloc_policy=FIFO SHOULD_MERGE|2 > > > > > > > 2) echo 128 > /sys/block/$DISK/queue/nr_requests and run your copy > > 1GB > > test again. > > done, and still fails. What to try next? I just run 256M cp test to one USB storage device on patched kernel, and WRITE data IO is really in ascending order. The filesystem is ext4, and mount without '-o sync'. From previous discussion, looks that is exactly your test setting. The order can be observed via the following script: #!/bin/sh MAJ=$1 MIN=$2 MAJ=$(( $MAJ << 20 )) DEV=$(( $MAJ | $MIN )) /usr/share/bcc/tools/trace -t -C \ 't:block:block_rq_issue (args->dev == '$DEV') "%s %d %d", args->rwbs, args->sector, args->nr_sector' $MAJ & $MIN can be retrieved via lsblk for your USB storage disk. So I think we need to check if the patch is applied correctly first. If your kernel tree is managed via git, please post 'git diff'. Otherwise, share us your kernel version, and I will send you one backported patch on the kernel version. Meantime, you can collect IO order log via the above script as you did last time, then send us the log. Thanks, Ming
