>>>>> "James" == James Bottomley <James.Bottomley@xxxxxxx> writes: >> I experimented with this approach a while back. However, I quickly >> got into a situation where frequently updated blocks never made it to >> disk because the page was constantly being updated. And all writes >> failed with a guard tag error. James> But that's unfixable with a retry based system as well if the James> page is changing so fast that the guard is always wrong by the James> time we get to the array. The only way to fix this is either to James> copy or freeze the page. Exactly, and that's why I'm in favor of the filesystems implementing whatever method they see fit for ensuring that pages don't change in flight. Whether that be locking, unmapping, or copying the page. If there's a performance hit we can have a flag that indicates whether this block device requires pages to be stable or not. I believe extN really depends on modifying pages for performance reasons. However, both XFS and btrfs seem to do just fine without it. Over time we'll have checksums coming down from userspace with various I/O submission interfaces, internally generated checksums for filesystem metadata, etc. I really don't think a one-size-fits-all retry heuristic is going to cut it. -- Martin K. Petersen Oracle Linux Engineering -- 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
