On Sunday March 18, davidsen@xxxxxxx wrote: > > This may be due to a characteristic of RAID1, which I believe Neil > described when discussing "check" failures in using RAID1 for swap. In > some cases, the data is being written from a user buffer, which is > changing. and the RAID software does two write, one to each device, > resulting in the data in the buffer changing as the write occurs. More > on this at the end. While you can get different data written to different devices in a RAID1, this difference is NEVER visible above the filesystem. It is mostly likely to happen with swap and, if it does, the swap system will never try to read that data back. It can conceivably happen with regular filesystems, but only if a file is being changed immediately before being truncated. Some of the blocks that were in the file might end up different on each device. But the data in those blocks will never be read (because the file has been truncated). So this could not explain the current problem. > > I do have a thought which MIGHT address this issue in a general way, > perhaps Neil will share he opinion. When writing to any array with > multiple copies which are written from user buffers, perhaps the code > could set the page(s) as copy on write. Then if the program tried to > modify the data it could be done safely. When the write to all drives > was complete, the COW could be cleared, and if the page had not been > modified very little overhead would be generated. If the page had been > modified, then the original would no longer be mapped to a process and > could be released. > > Neil, what think you? This would be e general solution to the mismatched > multiple copies issue, assuming that it could be done at all. Copy-on-write is not as easy as it sounds. Trying to trigger COW from the md driver would be incredibly messy and wouldn't solve any serious problem. NeilBrown - 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
