-----Original Message----- From: joystick [mailto:joystick@xxxxxxxxxxxxx] 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 >> ... >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
