On 15 March 2018 at 16:43, Bart Van Assche <Bart.VanAssche@xxxxxxx> wrote: > > Adding support for ZBC drives as a profile has a significant disadvantage, > namely that the different I/O patterns (sequential read, sequential write, > random read, random write, ...) all have to be reimplemented. That's why I'm > considering to add ZBC support by modifying what get_next_block() produces. > Can you have a look at the (barely tested) patch below? I don't have access to any ZBC devices but I looked over the patch. This seems to be a blend of both both of Philip's suggestions and I quite like it because it centralized most of the logic within the engine itself bar the offset fixing. Something that could help is if ioengines were able to specify a callbacks to say whether an offset + size is valid or whether the ioengine wants to "fix" them. If it says the offset is invalid we just quietly pretend we did the I/O, reduce the amount of I/O we have to do on this loop and generate the next offset + size. If it chooses to just fix it then we just use the different values it fixed the I/O to (assuming it fits alignment, minimum block sizes etc). How do people see fix mode interacting with things like bssplit? Do we just ban bssplit when in this mode for now? Most engines could leave these unset but it would be perfect for this one and it would stop the typical path having to depend on this particular ioengine being configured in. If fix things up mode is set then I suppose fio could then go on to ban things like lsfr, randommap and random_distribution. I guess one snag with re-rolling in "valid" mode is that you could end up re-rolling forever. I'm no expert but I'm hoping doing another if (engine defines block_checking) on every I/O won't have too much of a hit. Perhaps we just start with "fix" mode see how that goes and move on from there? Something else that could get hairy are verify jobs that are seperate from their write job because the offsets generated during a subsequent verify will not necessarily be invalid at the same points or changed the same way. I suppose inline verify should work assuming write regions haven't been reset due to becoming full. -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
