> On 12 Jan 2017, at 18:45, Eric Blake wrote:
>
> On 01/12/2017 11:57 AM, Bob Chen wrote:
>> There might be a time window between the NBD server's resize and the
>> client's `re-read size` request. Is it safe?
>
> For resize larger, it seems that it would be safe for the server to just
> rememb
On 01/12/2017 11:57 AM, Bob Chen wrote:
> There might be a time window between the NBD server's resize and the
> client's `re-read size` request. Is it safe?
For resize larger, it seems that it would be safe for the server to just
remember the last size it has advertised to the client. As long as
There might be a time window between the NBD server's resize and the
client's `re-read size` request. Is it safe?
What about an active `resize` request from the client? Considering some NBD
servers might have the capability to do instant resizing, not applying to
LVM or host block device, of cours
On Thu, Jan 12, 2017 at 3:44 PM, Alex Bligh wrote:
>> On 12 Jan 2017, at 14:43, Eric Blake wrote:
>> That's because the NBD protocol lacks a resize command. You'd have to
>> first get that proposed as an NBD extension before qemu could support it.
>
> Actually the NBD protocol lacks a 'make a di
> On 12 Jan 2017, at 14:43, Eric Blake wrote:
>
> That's because the NBD protocol lacks a resize command. You'd have to
> first get that proposed as an NBD extension before qemu could support it.
Actually the NBD protocol lacks a 'make a disk with size X' command,
let alone a resize command. T
On 01/12/2017 04:22 AM, Bob Chen wrote:
> Hi,
>
>
> My qemu runs on a 3rd party distributed block storage, and the disk backend
> protocol is nbd.
>
> I notices that there are differences between default qcow2 local disk and
> my nbd disk, in terms of resizing the disk on the fly.
>
> Local qco
On Wed, Jan 04, 2017 at 02:44:53PM -0600, Eric Blake wrote:
> On 01/04/2017 02:45 AM, Fangyi (C) wrote:
> > As we all know, socket is in blocking mode when nbd is negotiating
> > with the other end. If the network is poor because of delay or packet
> > loss, socket read or write will return ver
On Thu, Jan 12, 2017 at 10:42:41AM +, Peter Maydell wrote:
> On 12 January 2017 at 10:35, David Engraf wrote:
> > The CFI entry for sector length must be set to sector length per device.
> > This is important for boards using multiple devices like the ARM Vexpress
> > board (width = 4, device-
Am 12.01.2017 um 12:36 schrieb Andrew Jones:
On Thu, Jan 12, 2017 at 10:42:41AM +, Peter Maydell wrote:
On 12 January 2017 at 10:35, David Engraf wrote:
The CFI entry for sector length must be set to sector length per device.
This is important for boards using multiple devices like the ARM
The CFI entry for sector length must be set to sector length per device.
This is important for boards using multiple devices like the ARM
Vexpress board (width = 4, device-width = 2).
Linux and u-boots calculate the size ratio by dividing both values:
size_ratio = info->portwidth / info->chipw
On 12 January 2017 at 10:35, David Engraf wrote:
> The CFI entry for sector length must be set to sector length per device.
> This is important for boards using multiple devices like the ARM Vexpress
> board (width = 4, device-width = 2).
>
> Linux and u-boots calculate the size ratio by dividing
Hi,
My qemu runs on a 3rd party distributed block storage, and the disk backend
protocol is nbd.
I notices that there are differences between default qcow2 local disk and
my nbd disk, in terms of resizing the disk on the fly.
Local qcow2 disk could work no matter using qemu-img resize or qemu m
12 matches
Mail list logo
