Re: [Qemu-devel] I/O errors reported to guest for raw-image-file backed /dev/vda - but host sees no I/O errors

[Lutz Vieweg]

On 04/20/2016 04:38 PM, Lutz Vieweg wrote:
> I've now a
> > strace -f -p 10727 -e trace=pwrite,pwritev,fdatasync,file -t 2>&1 | gzip -1 -c 
> > >trace.gz
> attached to the qemu-process.
>
> If the incident rate stays the same, by tomorrow I should be able
> to correlate newly emitted I/O-errors in the guest with that log.

Ok, mystery solved:

> [pid 18241] 00:17:15 pwritev(16, [{..., 4096}, {..., 4096}], 2, 6585417728) = 
> -1 ENOSPC (No space left on device)
> [pid 18241] 00:17:15 pwrite(16, ..., 4096, 6581915648) = -1 ENOSPC (No space 
> left on device)
> [pid 18241] 00:17:15 pwrite(16, ..., 4096, 1048576) = -1 ENOSPC (No space left 
> on device)
> [pid 18241] 00:17:15 pwrite(16, ..., 4096, 1048576) = -1 ENOSPC (No space left 
> on device)

File descriptor fd=16 was associated with a raw image file that actually
resides on a btrfs filesystem, a constant-sized 16GB file with attributes
set to not use CopyOnWrite semantics.

Nevertheless, writes to such files can still yield ENOSPC due to a bug in btrfs:
> http://www.spinics.net/lists/linux-btrfs/msg52691.html

And indeed, the errors occured exactly at the time a backup procedure
was preparing a read-only snapshot with "btrfs subvolume snapshot -r" -
so until I can upgrade to a mainline kernel including the fix, I'll
pause the qemu process while the "btrfs subvolume snapshot -r" runs.

Thanks for the hints.
Sorry this turned out to be a btrfs rather than a qemu bug - I was
first misled to believe the image was on XFS.

Nevertheless, I think qemu could be somewhat more verbose, reporting
when and why it stops emulation. Something like a message to the monitor
or to standard out would be helpful to start with...

Regards,

Lutz Vieweg