linux-kernel - Continually increasing inflight IO statistics with md mirror and blk-mq enabled on 3.19 release

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-id: <3a774fb2.e494.14bc3b15a3f.Webtop.41@optonline.net>
Date:	Wed, 25 Feb 2015 21:22:34 -0500 (EST)
From:	james owens <jamesowens@...online.net>
To:	linux-kernel@...r.kernel.org
Subject: Continually increasing inflight IO statistics with md mirror and
 blk-mq enabled on 3.19 release

Please cc me personally on any replies as I am not a subscriber to the 
list.

I currently have a 2 device md raid 1 on my Linux workstation where the 
slave devices are usb 3.0 external drives 4 TB each which I use for 
backup purposes. I also have a 3ware 9750 RAID controller with a HW RAID 
1 SSD mirror and 12 drive RAID 6.

I recently installed the 3.19 release kernel from openSuSE current to 
try out the block-mq optimizations. The new mq subsystem is clearly 
enabled by the presence of the mq subdirectory under /sys/block/foo. The 
performance on the 3ware is great, especially the SSD mirror; however, 
when using the md RAID 1 with external USB 3.0 devices, I noticed the 
inflight IO counters at /sys/block/md127/inflight are continuously 
increasing. This is not normal as these should go to 0 once any pending 
reads/writes are finalized. Is this simply an accounting problem I can 
safely ignore, or is it an unsafe situation that I need to be concerned 
about?

Note that this does not occur with the exported disks on the 3ware array 
/dev/sda and /dev/sdb.

I could try and see if this happens with a plain USB drive as I have 
some available.

If you dismount the volume and stop the md array and then reassemble it, 
the statistics reset (as one would expect).

I use a bitmap file to speed up resyncs, and the bitmap file is 
clearing, and there is no filesystem corruption that I can see, so the 
writes are clearly getting to the disks correctly.

I will provide more information as best I can if needed. My guess is 
that this will be pretty easy to reproduce.

Best regards,

Jim Owens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/