On Wed, Mar 02, 2022 at 03:05:33PM -0700, Jens Axboe wrote: > On 3/2/22 2:54 PM, Luis Chamberlain wrote: > > On Wed, Mar 02, 2022 at 03:19:32PM +0000, David Howells wrote: > >> Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > >> > >>>> It'd be nice to be able to set up a 'configuration transaction' and then > >>>> do a commit to apply it all in one go. > >>> > >>> Can't io-uring cmd effort help here? > >> > >> I don't know. Wouldn't that want to apply each element as a separate thing? > > > > There is nothing to stop us to design an API which starts a > > transaction / ends. And io-uring cmd supports links so this is all > > possible in theory, I just don't think anyone has done it before. > > Only thing you're missing there is unroll on failure. It's quite > possible to have linked operations, but the only recurse is "abort rest > of chain if one fails". Yikes. I can see this getting complicated fast. But wouldn't dbs have already dealt with this somehow? But yes, my point still stands. io-uring cmd stuff really can be a game changer on how we deal with new APIs. While unifying arch stuff to make system calls easier to add, I'm actually thinking, if an async API is needed, then perhaps we can *curtail* adding new system calls and just handle these through the io-uring cmd stuff. Of course, so long as your subsystem deals with file_operations. > > I mean... io-uring cmd file operation stuff is not even upstream > > yet... > > Mostly because it hasn't been pushed. Was waiting for a good idea on how > to handle extended commands, and actually had the epiphany and > implemented it next week. So a more palatable version should be posted > soon. I am more than ecstatic to hear this! I cannot wait! > >> But you might want to do something more akin to a db transaction, where you > >> start a transaction, read stuff, consider your changes, propose your changes > >> and then commit - which would mean io_uring wouldn't help. > > > > I think Pavel had some advanced use cases to support that with io-uring > > cmd work. For instance open a file descriptor and then work on it all > > in the same chain of commands sent. > > That already exists in the kernel, it's direct descriptors. See: > > https://lwn.net/Articles/863071/ > > With that, you can have a chain that does "open file, do X to file, do Y > to file, etc, close file" in one operation. Links like mentioned above, > but can pre-make requests that operate on a descriptor that has been > opened. Groovy, thanks for the pointer! Luis
