Of course you could just run repair but then you would never know that
mismatch_cnt was 0.
Justin.
On Sat, 24 Feb 2007, Justin Piszcz wrote:
Perhaps,
The way it works (I believe is as follows)
1. echo check sync_action
2. If mismatch_cnt 0 then run:
3. echo repair sync_action
4. Re-run
I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5,
multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200
+).
I then ordered a resync. The mismatch_cnt returned to 0 at the start of
the resync, but around the same time that it went up to 8 with the
check, it went
A resync? You're supposed to run a 'repair' are you not?
Justin.
On Sat, 24 Feb 2007, Jason Rainforest wrote:
I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5,
multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200
+).
I then ordered a resync. The
Yes, I meant repair, sorry. I checked my bash history and I did indeed
order a repair (echo repair /sys/block/md0/md/sync_action). I think I
called it a resync because that's what /proc/mdstat told me it was
doing.
On Sat, 2007-02-24 at 04:50 -0500, Justin Piszcz wrote:
A resync? You're
Ahh, perhaps Neil can fix that? ;)
Cat /sys/block/md0/md/sync_action will tell you what it is really doing.
On Sat, 24 Feb 2007, Jason Rainforest wrote:
Yes, I meant repair, sorry. I checked my bash history and I did indeed
order a repair (echo repair /sys/block/md0/md/sync_action). I think
Jason Rainforest wrote:
I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5,
multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200
+).
I then ordered a resync. The mismatch_cnt returned to 0 at the start of
As pointed out later it was repair, not resync.
On Sat, 24 Feb 2007, Michael Tokarev wrote:
Jason Rainforest wrote:
I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5,
multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200
+).
I then ordered a resync. The mismatch_cnt returned to 0 at the start of
As
On Fri, Feb 23, 2007 at 09:32:29PM -0500, Theodore Tso wrote:
And having a way of making this list available to both the
filesystem and to a userspace utility, so they can more easily deal
with doing a forced rewrite of the bad sector, after determining
which file is involved and perhaps
In contrast, ever since these holes appeared, drive failures became the norm.
wow, great conspiracy theory! maybe the hole is plugged at
the factory with a substance which evaporates at 1/warranty-period ;)
seriously, isn't it easy to imagine a bladder-like arrangement that
permits
