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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ