I talked with some folks in the hall about ATOMIC storage operations (commands in the disks to guarantee atomicity). Further questions have come up on which I'd like additional feedback. This is specifically about a single extent atomic command (1 LBA + 1 length). I'd like input from anyone that might use atomic commands (Database, Filesystem, etc), so please forward to anyone that might be interested. When it works, the definition is simple - either all blocks got written, or none of them got written. Some have indicated that specifying a granularity of atomicity would be useful. Meaning, a larger operation could be broken into smaller atomic segments. For example, a 64K write could specify all 64K is written, or none of it is written; OR, a 64K write could specify that it is 8K (or some other number) granular (meaning the atomicity is guaranteed on the specified boundaries (8K in this example)). But that brings a couple possible error scenarios into play (when something goes wrong on a granular operation - I've used an example where the host asked for 8K granularity): 1) The device manages each 8K segment independently, if an error happens then you don't know which 8K segments have been written or not. You DO know that if an 8K segment had anything written to it, then everything was written to it, because it is an 8K ATOMIC segment. But each 8K segment is independently managed by the device. 2) The device manages the 8K granularity as a tear point. If an error occurs, the device guarantees everything up to an 8K boundary was written, and nothing after the 8K boundary was written. Do the use cases for single range atomic commands fit one or the other of those models better? How would you do error recovery if a granular atomic command failed? Would model 1 or model 2 work better for error recovery? Fred Knight h -- 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
