search for: copy_size

I noticed the "XXX: what should this be?" w.r.t. COPY_SIZE in sftp-client.c. I made up the following quick patch to allow a new command-line argument, "-B" (for 'buffer' size) to specify this value. I haven't done any strict benchmarking yet, but -B65535 is faster than -B8192 which is much faster than -B16. PS again, I am not on...

...ev_or_Path "pathordevice"], [OBool "force"; OBool "lazyunmount"]; fish_alias = ["unmount"]; @@ -5479,26 +5425,6 @@ calls to associate logical volumes and volume groups. See also C<guestfs_vgpvuuids>." }; { defaults with - name = "copy_size"; added = (1, 0, 87); - style = RErr, [Dev_or_Path "src"; Dev_or_Path "dest"; Int64 "size"], []; - progress = true; deprecated_by = Some "copy_device_to_device"; - tests = [ - InitScratchFS, Always, TestResult ( - [["mkdir"...

...imum (6). That makes sure we do not waste packets for short files or some obvious error cases. There are two ideas I have not tried yet. the first is not to use the file size from the stat call to avoid issuing more than one request past the presumed end-of-file. The other idea is to start with COPY_SIZE requests, but to use the size of the responses (which might be less then COPY_SIZE) for future requests. The reason for doing this is to avoid non-sequential requests to servers with small maximum responses sizes. That way we could also increase COPY_SIZE to something more efficient. Does anyon...

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

...static ssize_t fill_readbuf(struct virtio_console_port *port, + char *out_buf, size_t out_count, bool to_user) +{ + struct virtio_console_port_buffer *buf, *buf2; + ssize_t out_offset, ret; + + out_offset = 0; + list_for_each_entry_safe(buf, buf2, &port->readbuf_head, next) { + size_t copy_size; + + copy_size = out_count; + if (copy_size > buf->len - buf->offset) + copy_size = buf->len - buf->offset; + + if (to_user) { + ret = copy_to_user(out_buf + out_offset, + buf->buf + buf->offset, + copy_size); + /* FIXME: Deal with ret != 0 */ + } else {...

...static ssize_t fill_readbuf(struct virtio_console_port *port, + char *out_buf, size_t out_count, bool to_user) +{ + struct virtio_console_port_buffer *buf, *buf2; + ssize_t out_offset, ret; + + out_offset = 0; + list_for_each_entry_safe(buf, buf2, &port->readbuf_head, next) { + size_t copy_size; + + copy_size = out_count; + if (copy_size > buf->len - buf->offset) + copy_size = buf->len - buf->offset; + + if (to_user) { + ret = copy_to_user(out_buf + out_offset, + buf->buf + buf->offset, + copy_size); + /* FIXME: Deal with ret != 0 */ + } else {...

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine*. There are a few items on my todo list but this works well. New since last send: - live migration support** - write path in the guest

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine*. There are a few items on my todo list but this works well. New since last send: - live migration support** - write path in the guest

Folks, I've noticed poor performance using sftp. If anyone has any advice on how to improve performance, I'd like to hear it. Test simply involved transferring a single 143MB MP3 file using defaults for all the program configs. The opensshd 3.0.2p1 server is used in all tests. Software: openssh suite 3.0.2p1 psftp (putty sftp client) latest dev snapshot pscp (putty scp client) latest

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. There are a few items on my

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. There are a few items on my

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

...they are expected to run. This is also a basic usability principle, see for example this paper: http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf If you look at how virt-resize is implemented, the bulk of the time is spent copying partitions in a single long-running function, copy_size: http://libguestfs.org/guestfs.3.html#guestfs_copy_size The current protocol is entirely synchronous so that while the daemon is doing the copy_size, the library is blocked waiting for a reply message and does nothing else in that thread. To implement a progress bar for this call we'd have...

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

...;f_flags & O_NONBLOCK) + return -EAGAIN; + + ret = wait_event_interruptible(port->waitqueue, + !list_empty(&port->readbuf_head)); + } + if (ret < 0) + return ret; + + ubuf_offset = 0; + list_for_each_entry_safe(buf, buf2, &port->readbuf_head, next) { + size_t copy_size; + + copy_size = count; + if (copy_size > buf->len - buf->offset) + copy_size = buf->len - buf->offset; + + ret = copy_to_user(ubuf + ubuf_offset, buf->buf + buf->offset, + copy_size); + + /* FIXME: Deal with ret != 0 */ + /* Return the number of bytes actually cop...