Chris Mason <chris.mason@xxxxxxxxxxxx> writes: > This allows filesystems and O_DIRECT to send down a list of bios > flagged for atomic completion. If the hardware supports atomic > IO, it is given the whole list in a single make_request_fn > call. > > In order to limit corner cases, there are a few restrictions in the > current code: > > * Every bio in the list must be for the same queue > > * Every bio must be a simple write. No trims or reads may be mixed in > > A new blk_queue_set_atomic_write() sets the number of atomic segments a > given driver can accept. > > Any number greater than one is allowed, but the driver is expected to > do final checks on the bio list to make sure a given list fits inside > its atomic capabilities. Hi, Chris, This is great stuff. I have a couple of high level questions that I'm hoping you can answer, given that you're closer to the hardware than most. What constraints can we expect hardware to impose on atomic writes in terms of size and, um, contiguousness (is that a word)? How do we communicate those constraints to the application? (I'm not convinced a sysfs file is adequate.) For example, looking at NVMe, it appears that devices may guarantee that a set of /sequential/ logical blocks may be completed atomically, but I don't see a provision for disjoint regions. That spec also differentiates between power fail write atomicity and "normal" write atomicity. Basically, I'd like to avoid requiring a trial and error programming model to determine what an application can expect to work (like we have with O_DIRECT right now). Cheers, Jeff -- 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
