Theodore Tso wrote:
On Fri, Mar 21, 2008 at 03:52:31PM +0100, Peter Rabbitson wrote:
I was actually specifically advocating that md must _not_ do anything on
its own. Just provide the hooks to get information (what is the current
stripe state) and update information (the described repair extension). The
logic that you are describing can live only in an external app, it has no
place in-kernel.
Why not? If md doesn't do anything on its own, then when it detects a
disagreement between the data and the two parity blocks, it has two
choices (a) return possibly incorrect data to the application, or (b)
return an I/O error and cause the application to blow up.
<snip>
So what's the harm in having an option where md does exactly what ECC
memory does, which is when it can fix things up, to do so? I bet most
system administrators would turn it on in a heartbeat.
With ECC memory you are checking for inconsistency on _every_single_read_
whereas the md scrubbing happens at best once a month if the admin turned the
feature on. Moreover when md actually detects a mismatch the overwhelming
chance is nobody needs this block at this moment, and might not need it for
days to come. I think what is eluding this thread is the fact that md does not
read _any_ redundant blocks unless it absolutely has to. And when it has to -
you already have a missing chunk and can not apply ECC techniques either.
Of course it would be possible to instruct md to always read all data+parity
chunks and make a comparison on every read. The performance would not be much
to write home about though.
Peter
--
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
