On Thu, Jun 03, 2010 at 11:46:34AM -0400, Chris Mason wrote: > On Wed, Jun 02, 2010 at 11:41:21PM +1000, Nick Piggin wrote: > > Closing the while it is dirty, while it is being written back window > > still leaves a pretty big window. Also, how do you handle mmap writes? > > Write protect and checksum the destination page after every store? Or > > leave some window between when the pagecache is dirtied and when it is > > written back? So I don't know whether it's worth putting a lot of effort > > into this case. > > So, changing gears to how do we protect filesystem page cache pages > instead of the generic idea of dif/dix, btrfs crcs just before writing, > which does leave a pretty big window for the page to get corrupted. > The storage layer shouldn't care or know about that though, we hand it a > crc and it makes sure data matching that crc goes to the media. I think the only way to get accurate CRCs is to stop modifications from occurring while the page is under writeback. i.e. when a page transitions from dirty to writeback we need to unmap any writable mappings on the page, and then any new modifications (either by the write() path or through ->fault) need to block waiting for page writeback to complete before they can proceed... If we can lock out modification during writeback, we can calculate CRCs safely at any point in time the page is not mapped. e.g. we could do the CRC calculation at copy-in time and store it on new pages. During writeback, if the page has not been mapped then the stored CRC can be used. If it has been mapped (say writeable mappings clear the stored CRC during ->fault) then we can recalculate the CRC once we've transitioned the page to being under writeback... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
