Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-19 Thread Emanuele Giuseppe Esposito
On 19/11/2021 04:13, Paolo Bonzini wrote: El jue., 18 nov. 2021 16:31, Hanna Reitz > escribió: On 18.11.21 14:50, Paolo Bonzini wrote: > On 11/15/21 17:03, Hanna Reitz wrote: >> >> I only really see four solutions for this: >> (1) We someho

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-18 Thread Paolo Bonzini
El jue., 18 nov. 2021 16:31, Hanna Reitz escribió: > On 18.11.21 14:50, Paolo Bonzini wrote: > > On 11/15/21 17:03, Hanna Reitz wrote: > >> > >> I only really see four solutions for this: > >> (1) We somehow make the amend job run in the main context under the > >> BQL and have it prevent all con

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-18 Thread Hanna Reitz
On 18.11.21 14:50, Paolo Bonzini wrote: On 11/15/21 17:03, Hanna Reitz wrote: I only really see four solutions for this: (1) We somehow make the amend job run in the main context under the BQL and have it prevent all concurrent I/O access (seems bad) (2) We can make the permission functions pa

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-18 Thread Hanna Reitz
On 18.11.21 15:04, Paolo Bonzini wrote: On 11/15/21 17:03, Hanna Reitz wrote: and second fuse_do_truncate(), which calls blk_set_perm(). Here it seems that a non-growable export is still growable as long as nobody is watching. :)  Is this the desired behavior? Yes, absolutely.  “Growable” i

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-18 Thread Paolo Bonzini
On 11/15/21 17:03, Hanna Reitz wrote: and second fuse_do_truncate(), which calls blk_set_perm(). Here it seems that a non-growable export is still growable as long as nobody is watching. :) Is this the desired behavior? Paolo

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-18 Thread Paolo Bonzini
On 11/15/21 17:03, Hanna Reitz wrote: I only really see four solutions for this: (1) We somehow make the amend job run in the main context under the BQL and have it prevent all concurrent I/O access (seems bad) (2) We can make the permission functions part of the I/O path (seems wrong and prob

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-15 Thread Daniel P . Berrangé
On Mon, Nov 15, 2021 at 05:03:28PM +0100, Hanna Reitz wrote: > On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: > > Currently, block layer APIs like block-backend.h contain a mix of > > functions that are either running in the main loop and under the > > BQL, or are thread-safe functions and ru

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-11-15 Thread Hanna Reitz
On 25.10.21 12:17, Emanuele Giuseppe Esposito wrote: Currently, block layer APIs like block-backend.h contain a mix of functions that are either running in the main loop and under the BQL, or are thread-safe functions and run in iothreads performing I/O. The functions running under BQL also take

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-10-28 Thread Stefan Hajnoczi
On Mon, Oct 25, 2021 at 06:17:10AM -0400, Emanuele Giuseppe Esposito wrote: > Currently, block layer APIs like block-backend.h contain a mix of > functions that are either running in the main loop and under the > BQL, or are thread-safe functions and run in iothreads performing I/O. > The functions

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-10-28 Thread Stefan Hajnoczi
On Mon, Oct 25, 2021 at 04:09:41PM +0200, Philippe Mathieu-Daudé wrote: > On 10/25/21 12:17, Emanuele Giuseppe Esposito wrote: > [...] > > > Each function in the GS API will have an assertion, checking > > that it is always running under BQL. > > I/O functions are instead thread safe (or so should

Re: [PATCH v4 00/25] block layer: split block APIs in global state and I/O

2021-10-25 Thread Philippe Mathieu-Daudé
On 10/25/21 12:17, Emanuele Giuseppe Esposito wrote: [...] > Each function in the GS API will have an assertion, checking > that it is always running under BQL. > I/O functions are instead thread safe (or so should be), meaning > that they *can* run under BQL, but also in an iothread in another >