From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Davidsen Subject: Re: Why does one get mismatches? Date: Fri, 26 Feb 2010 15:48:58 -0500 Message-ID: <4B8833BA.4010503@tmr.com> References: <869541.92104.qm@web51304.mail.re2.yahoo.com> <4B67451F.8040206@tmr.com> <20100202093738.44b4fece@notabene.brown> <4B684087.50001@tmr.com> <20100211161444.7a0ea7bb@notabene.brown> <20100211175133.GA30187@atlantis.cc.ndsu.nodak.edu> <4B7B0D45.7040801@tmr.com> <6db64f7872286165ac1fd3436e9d6476@localhost> <20100218100547.7aecdc34@notabene.brown> <20100219151809.GB4995@lazy.lzy> <20100220090208.06c1130f@notabene.brown> <4B853D99.1040902@tmr.com> <20100225083748.42f024aa@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100225083748.42f024aa@notabene.brown> Sender: linux-raid-owner@vger.kernel.org To: Neil Brown Cc: Piergiorgio Sartor , Steven Haigh , Bryan Mesich , Jon@eHardcastle.com, linux-raid@vger.kernel.org List-Id: linux-raid.ids Neil Brown wrote: > On Wed, 24 Feb 2010 09:54:17 -0500 > Bill Davidsen wrote: > > >> Neil Brown wrote: >> >>> md is not in a position to lock the page - there is simply no way it can stop >>> the filesystem from changing it. >>> The only thing it could do would be to make a copy, then write the copy out. >>> This would incur a performance cost. >>> >>> >>> >> Two thoughts on that - one is that for critical data, give me the option >> at array start time, make the copy, slow the performance and make it >> more consistent. My second thought is that a checksum of the page before >> initiating write and after all writes are complete might be less of a >> performance hit, and still could detect that the buffer had changed. >> > > > The idea of calculating a checksum before and after certainly has some merit, > if we could choose a checksum algorithm which was sufficiently strong and > sufficiently fast, though in many cases a large part of the cost would just be > bringing the page contents into cache - twice. > > It has the advantage over copying the page of not needing to allocate extra > memory. > > If someone wanted to try an prototype this and see how it goes, I'd be happy > to advise.... > Disagree if you wish, but MD5 should be fine for this. While it is not cryptographically strong on files, where the size can be changed and evil doers can calculate values to add at the end of the data, it should be adequate on data of unchanging size. It's cheap, fast, and readily available. -- Bill Davidsen "We can't solve today's problems by using the same thinking we used in creating them." - Einstein