On Mon, Aug 19, 2019 at 9:04 PM Eric Blake wrote:
> On 8/17/19 8:31 PM, Nir Soffer wrote:
> >>> Also, for qemu-nbd, shouldn't we allow -e only together with -r ?
> >>
> >> I'm reluctant to; it might break whatever existing user is okay exposing
> >> it (although such users are questionable, so
On 8/17/19 8:31 PM, Nir Soffer wrote:
>>> Also, for qemu-nbd, shouldn't we allow -e only together with -r ?
>>
>> I'm reluctant to; it might break whatever existing user is okay exposing
>> it (although such users are questionable, so maybe we can argue they
>> were already broken). Maybe it's
On Sat, Aug 17, 2019 at 5:30 PM Eric Blake wrote:
> On 8/16/19 5:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> >>> +++ b/blockdev-nbd.c
> >>> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
> has_name, const char *name,
> >>> }
> >>>
> >>> exp =
On 8/15/19 5:54 PM, Eric Blake wrote:
> On 8/15/19 4:45 PM, John Snow wrote:
>>
>>
>> On 8/15/19 2:50 PM, Eric Blake wrote:
>>> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
>>> advertised when the server promises cache consistency between
>>> simultaneous clients
On 8/15/19 4:45 PM, John Snow wrote:
>
>
> On 8/15/19 2:50 PM, Eric Blake wrote:
>> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
>> advertised when the server promises cache consistency between
>> simultaneous clients (basically, rules that determine what FUA and
>> flush
On 8/15/19 2:50 PM, Eric Blake wrote:
> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
> advertised when the server promises cache consistency between
> simultaneous clients (basically, rules that determine what FUA and
> flush from one client are able to guarantee for
