similar to: [PATCH v2] resize, builder: fsync the output file before closing the libvirt connection.

Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is writing to a slow USB key, it can hang (in D state) for much longer than this - many minutes usually. To work around this, fsync the output file before closing the libvirt connection so that qemu shouldn't have anything (much) to write. We have to do this in two places in the code since we can reopen the connection (if using

On Tue, Jan 19, 2016 at 04:18:46PM +0000, Richard W.M. Jones wrote: > Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is > writing to a slow USB key, it can hang (in D state) for much longer > than this - many minutes usually. > > The solution is to check specifically for the libvirt EBUSY error when > this happens, and retry the virDomainDestroyFlags operation

On Tue, Jan 19, 2016 at 05:00:27PM +0000, Daniel P. Berrange wrote: > On Tue, Jan 19, 2016 at 04:18:46PM +0000, Richard W.M. Jones wrote: > > Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is > > writing to a slow USB key, it can hang (in D state) for much longer > > than this - many minutes usually. > > > > The solution is to check specifically

Libvirt has a fixed 15 second timeout for qemu to exit. If qemu is writing to a slow USB key, it can hang (in D state) for much longer than this - many minutes usually. The solution is to check specifically for the libvirt EBUSY error when this happens, and retry the virDomainDestroyFlags operation (indefinitely). See also the description here:

Changed disk GUID makes some OSes fail to boot. To enable virt-resize to support such OSes we have to preserve disk GUID. --- resize/resize.ml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/resize/resize.ml b/resize/resize.ml index d6dd9a5..8ff4793 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -407,6 +407,13 @@ read the man page virt-resize(1).

While working bug #143, it came to my attention that no verbose error is loged if the dom0 kernel mangles a packet and tries to checksum offload it. This should let the user know what is going wrong (instead of silently dropping the packet). Signed-off-by: Jon Mason <jdmason@us.ibm.com> # HG changeset patch # User root@opteron.ltc.austin.ibm.com # Node ID

Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> --- resize/resize.ml | 82 +++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 72 insertions(+), 10 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index 3f804a0..ea0be9e 100644 --- a/resize/resize.ml +++ b/resize/resize.ml @@ -596,6 +596,8 @@ read the man page virt-resize(1). let hash = Hashtbl.create 13

Some OSes (e.g. Windows Server 2012 R2) fail to boot after virt-resize due to changed disk guid. To fix it, we add new APIs: part_get_disk_guid part_set_disk_guid part_set_disk_guid_random We also preserve disk GUID in virt-resize. Maxim Perevedentsev (3): New API: part_get_disk_guid and part_set_disk_guid. New API: part_set_disk_guid_random. resize: preserve GPT disk GUID.

Certain transitions where the input and output filename are the same are impossible, eg copying a file to itself. Don't add these. Reported-by: David Kaylor. --- builder/builder.ml | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/builder/builder.ml b/builder/builder.ml index a4c830e89..843106a86 100644 --- a/builder/builder.ml +++

--- builder/builder.ml | 84 +++++++++++++++++++++++++++++++++---------- common/mlutils/unix_utils-c.c | 27 ++++++++++++++ common/mlutils/unix_utils.ml | 3 ++ common/mlutils/unix_utils.mli | 4 +++ m4/guestfs_libraries.m4 | 1 + 5 files changed, 100 insertions(+), 19 deletions(-) diff --git a/builder/builder.ml b/builder/builder.ml index d8e625f68..fd19aa7d9 100644 ---

Does Fsync of a file on a ext3 fs mounted with "ordered" option(the default) result in flush the dirty data buffers in the fs that correspond to previous transactions. In other words, if I keep writing to file1 (lots of data), log something to file2, keep fsyncing file2 after every write - does this mean file1 data would be committed by fsyncs on file2. Please copy me on your replies

Hi, I have a question on fsync() and ext3's journaling modes. Assume that I call fsync(fd) on a file. If that file is in 'data=journal' mode, would the fsync() return once the data gets safely into the journal ? On the other hand, if that file is in 'data=writeback' mode, would the fsync() return only when the data gets safely into its actual location ? Any help is

If I want to make sure a file has really been deleted do I have to: 1. fsync the file 2. fsync the directory the file is in 3. both? Much thanks. -- Ben Escoto

I'm currently looking at the behaviour of various Linux filesystems as backends for the Cyrus IMAP server. Like many mail applications, Cyrus makes heavy use of the fsync() system call to ensure that data has hit stable storage before it acknowledges receipt of messages. At the moment fsync() appears to introduce lots of synchronous I/O as data is flushed all the way through to the filesystem

On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity <avi@redhat.com> wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen<andi@firstfloor.org> wrote: > > > >> Ben Gamari<bgamari.foss@gmail.com> writes: > >> ext4/XFS/JFS/btrfs should be better in this regard > >> > >> >

Author: perrin Repository: /hg/zfs-crypto/gate Revision: a593e64c4739242e2eb3a43ea296996000af0c2d Log message: 6413731 pathologically slower fsync on 32 bit systems Files: update: usr/src/uts/common/fs/zfs/sys/zil.h update: usr/src/uts/common/fs/zfs/zil.c

https://bugzilla.mindrot.org/show_bug.cgi?id=1798 Daniel Black <daniel.subs at internode.on.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.subs at internode.on.ne | |t -- You are receiving

This check for a user transaction is a bogus: fsync() with an open user transaction is verboten. If the caller is the same process who started a user transaction, and this is a different file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to

https://bugzilla.mindrot.org/show_bug.cgi?id=1798 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |2130 --- Comment #16 from Damien Miller <djm at mindrot.org> --- Retarget to openssh-6.4 -- You are

This is by no means a complete fix for RHBZ#836710, because I haven't completely got to the bottom of this bug yet, but it is an improvement. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd