On Sat, Jul 16, 2016 at 4:56 PM, Wouter Verhelst wrote:
> On Sat, Jul 16, 2016 at 03:38:40PM +0530, Pranay Srivastava wrote:
>> Okay. So how about we include some negotiated key which goes in with every
>> request which the server could maintain for clients that can be checked while
>> resetting t
On Sat, Jul 16, 2016 at 03:38:40PM +0530, Pranay Srivastava wrote:
> Okay. So how about we include some negotiated key which goes in with every
> request which the server could maintain for clients that can be checked while
> resetting the connection with the same server?
Wut?
> So am I correct t
On Sat, Jul 16, 2016 at 3:02 PM, Alex Bligh wrote:
>
> On 16 Jul 2016, at 08:42, Pranay Srivastava wrote:
>
>> So instead can't we put a mechanism in place for network address + mac
>> to be same
>> for allowing clients to reconnect? Do let me know if this is not of concern.
>
> MAC address?! nbd
On 16 Jul 2016, at 08:42, Pranay Srivastava wrote:
> So instead can't we put a mechanism in place for network address + mac
> to be same
> for allowing clients to reconnect? Do let me know if this is not of concern.
MAC address?! nbd clients connect over IP, and if a router reboots
between them
Hi,
On Fri, Jun 24, 2016 at 2:59 PM, Markus Pargmann wrote:
> After NBD_DO_IT exited the block device may still be used. Make sure
> that we handle intended disconnects differently and do not allow any
> changed of the nbd device.
>
> This patch should avoid that the nbd-client connects to a diff
After NBD_DO_IT exited the block device may still be used. Make sure
that we handle intended disconnects differently and do not allow any
changed of the nbd device.
This patch should avoid that the nbd-client connects to a different server
and the users of the block device are suddenly reading/wri
6 matches
Mail list logo
