From: "Guy Watkins" <linux-raid@watkins-home.com>
To: 'Mikael Abrahamsson' <swmike@swm.pp.se>,
'Linux RAID' <linux-raid@vger.kernel.org>
Subject: RE: feature suggestion to handle read errors during re-sync of raid5
Date: Mon, 01 Feb 2010 08:33:40 -0500 [thread overview]
Message-ID: <E15146CE216E4737A20C4EC59D414720@m5> (raw)
In-Reply-To: <alpine.DEB.1.10.1002010814080.31777@uplift.swm.pp.se>
I have always read that drives remap on failed write.
But have not read anything new in 2+ years.
} -----Original Message-----
} From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-
} owner@vger.kernel.org] On Behalf Of Mikael Abrahamsson
} Sent: Monday, February 01, 2010 2:16 AM
} To: Linux RAID
} Subject: Re: feature suggestion to handle read errors during re-sync of
} raid5
}
} On Sun, 31 Jan 2010, Roger Heflin wrote:
}
} > Bit errors seem more likely the longer a sector has set since being
} > written. I would be not expect to see errors if you read the entire
} > disk, and then reread it 1x a day for a year, but if you read the disk
} > once, let it sit spinning for a year without any reads and read it
} > again, this will almost certainly get a read error. When you keep
} > rereading it, when the bits start to go bad the disk should move it long
} > before data loss happens, but if you only read it 1x a year, it is
} > likely that when you find the data bad there will be too many bad bits,
} > beyond being able to correct it.
}
} Are you sure that drives today remap like that (if it tries to read it and
} only succeeds on the 5th try, it'll reallocate the sector)?
}
} Looking at "reallocated sectors" on my drives, I've never seen this
} happen. That SMART parameter has never increased unless I had a hard UNC
} and re-wrote the sector (and a lot of the times, not even that).
}
} --
} Mikael Abrahamsson email: swmike@swm.pp.se
} --
} To unsubscribe from this list: send the line "unsubscribe linux-raid" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-02-01 13:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 12:37 feature suggestion to handle read errors during re-sync of raid5 Mikael Abrahamsson
2010-01-30 17:51 ` Giovanni Tessore
2010-01-30 19:04 ` John Robinson
2010-01-30 21:33 ` Mikael Abrahamsson
2010-01-30 22:04 ` Asdo
2010-01-30 22:25 ` Mikael Abrahamsson
2010-01-31 16:17 ` John Robinson
2010-01-31 16:34 ` Asdo
2010-01-31 18:04 ` Goswin von Brederlow
2010-01-31 17:56 ` Mikael Abrahamsson
2010-02-01 1:30 ` Roger Heflin
2010-02-01 7:15 ` Mikael Abrahamsson
2010-02-01 13:33 ` Guy Watkins [this message]
2010-02-01 13:42 ` Mikael Abrahamsson
2010-02-01 15:15 ` Goswin von Brederlow
2010-02-01 16:28 ` Mikael Abrahamsson
2010-02-01 20:30 ` Richard Scobie
2010-02-02 11:06 ` John Robinson
2010-01-30 21:09 ` Asdo
2010-01-30 18:59 ` Goswin von Brederlow
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=E15146CE216E4737A20C4EC59D414720@m5 \
--to=linux-raid@watkins-home.com \
--cc=linux-raid@vger.kernel.org \
--cc=swmike@swm.pp.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox