-----Original Message-----
From: joystick [mailto:joystick@shiftmail.org] 
Sent: Sunday, November 10, 2013 7:46 AM
To: Justin Piszcz
Cc: 'linux-raid'
Subject: Re: 3.12: raid-1 mismatch_cnt question

[ .. ]

You mean that you *repaired* the mismatches, then waited without 
rebooting, then repeated the check and there were again mismatches?

Yes.

[ .. ]

( # dd if=/dev/zero of=emptyfile bs=1M count=62464; now perform the check
for mismatches with emptyfile still on the filesystem. Delete only
afterwards; This should keep Trim effects mostly out of the game; # echo
check > /sys/devices/virtual/block/md1/md/sync_action; # rm emptyfile )

Had 103GB free, so:

$ dd if=/dev/zero of=emptyfile bs=1M count=100000 (4.8GB free after)
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 193.335 s, 542 MB/s

echo check > /sys/devices/virtual/block/md1/md/sync_action

cat /sys/devices/virtual/block/md1/md/mismatch_cnt
32640

quoted

...
4) Theories above do not explain why you see an improvement dropping

caches. This is very interesting. How do you exactly drop the caches?

In short:
1.   sync
2.   echo 1 > /proc/sys/vm/drop_caches
3.   sync
4.   echo check > sync_action
[ .. ]
5.  if mismatch_cnt > 0
6.  repeat 1-3 above
7.  echo repair > sync_action

The only reason I can think of, for which dropping in this way might 
help, is if Trim-med areas return nonzero upon read for such SSD. In 
that case the cache and the device return different values upon read.

I think the kernel should drop the cache of trimmed areas. Probably this 
is not implemented yet. Can anybody confirm?

[ .. ]

One answer is missing: has it got deterministic read data after trim?
# hdparm -I /dev/sdX | grep TRIM
does it contain something like " * Deterministic read data after TRIM" ?

[ .. ]

Yes.

# hdparm -I /dev/sdb|grep "TRIM"
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM
# hdparm -I /dev/sdc|grep "TRIM"
           *    Data Set Management TRIM supported (limit 1 block)
           *    Deterministic read data after TRIM

I would not trust this 100% anyways; the new test I suggested for point 
2 above should be more reliable.

[ .. ]

Ok.

Justin.