From: "Justin Piszcz" <jpiszcz@lucidpixels.com>
To: 'joystick' <joystick@shiftmail.org>
Cc: 'linux-raid' <linux-raid@vger.kernel.org>
Subject: RE: 3.12: raid-1 mismatch_cnt question
Date: Mon, 11 Nov 2013 04:26:37 -0500 [thread overview]
Message-ID: <000301cedec0$1fa72d60$5ef58820$@lucidpixels.com> (raw)
In-Reply-To: <527F7FF5.3000002@shiftmail.org>
-----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
>> ...
>> 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.
next prev parent reply other threads:[~2013-11-11 9:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-04 10:25 3.12: raid-1 mismatch_cnt question Justin Piszcz
2013-11-04 10:25 ` Justin Piszcz
2013-11-07 10:54 ` Justin Piszcz
2013-11-12 0:39 ` Brad Campbell
2013-11-12 9:14 ` Justin Piszcz
[not found] ` <527E8B74.70301@shiftmail.org>
2013-11-09 22:49 ` Justin Piszcz
2013-11-10 12:45 ` joystick
2013-11-11 9:26 ` Justin Piszcz [this message]
2013-11-11 11:06 ` joystick
2013-11-11 18:52 ` Justin Piszcz
2013-11-11 21:23 ` John Stoffel
2013-11-11 21:55 ` NeilBrown
2013-11-12 2:49 ` John Stoffel
2013-11-11 21:58 ` NeilBrown
2013-11-11 22:18 ` Justin Piszcz
2013-11-12 9:30 ` joystick
2013-11-12 10:29 ` Bernd Schubert
2013-11-13 22:10 ` Justin Piszcz
2013-11-14 8:44 ` joystick
2013-11-14 10:43 ` Justin Piszcz
2013-11-14 16:09 ` joystick
2013-11-14 17:22 ` Justin Piszcz
2013-11-15 8:51 ` joystick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000301cedec0$1fa72d60$5ef58820$@lucidpixels.com' \
--to=jpiszcz@lucidpixels.com \
--cc=joystick@shiftmail.org \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.