Re: Why does one get mismatches?

[Michael Evans <mjevans1983@gmail.com>]

On Fri, Feb 26, 2010 at 2:20 PM, Asdo <asdo@shiftmail.org> wrote:
> Neil Brown wrote:
>>
>> Actually, I'm no longer convinced that the checksumming idea would work.
>> If a mem-mapped page were written, that the app is updating every
>> millisecond (i.e. less than the write latency), then every time a write
>> completed the checksum would be different so we would have to reschedule
>> the
>> write, which would not be the correct behaviour at all.
>> So I think that the only way to address this in the md layer is to copy
>> the data and write the copy.  There is already code to copy the data for
>> write-behind that could possible be leveraged to do a copy always.
>>
>
> The concerns of slowdowns with copy could be addressed by making the copy a
> runtime choice triggered by a sysctl interface, a file in /sys/block/mdX/md/
> interface where one can echo "1" to enable copies for this type of raid. Or
> better 1 could be the default (slower but safer, or if not safer, at least
> to avoid needless questions on mismatches on this ML by new users, and to
> allow detection of REAL mismatches which can be due to cabling or defective
> disks) and echoing 0 would increase performances at the cost of seeing lots
> of false positive mismatches.
> --
> 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
>

Isn't there some way of making the page copy-on-write using hardware
and/or an in-kernel structure?  Ideally copying could be avoided
/unless/ there is change.  That way each operation looks like an
atomic commit.
--
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