On Thu, May 5, 2011 at 10:59 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Thu, May 05, 2011 at 12:44:38PM -0400, T Johnson wrote:
> I've been strapped for time to work on this lately, but have a couple
> updates. I have been using the updated RHEL 6.1 packages, so
> unfortunately that doesn't seem to solve the problem yet.
>
> I'm still having some trouble capturing all the output, but I have
> manged to collect this verbose output after aborting a "stalled"
> request:
>
> [ 35.206396] end_request: I/O error, dev vda, sector 2048
> [ 35.207363] Buffer I/O error on device vda1, logical block 0
> [ 35.207384] lost page write due to I/O error on vda1
> [ 35.207384] Buffer I/O error on device vda1, logical block 1
> [ 35.207384] lost page write due to I/O error on vda1
> [ 35.207384] end_request: I/O error, dev vda, sector 1574912
> [ 35.207384] Buffer I/O error on device vda1, logical block 196608
> [ 35.207384] lost page write due to I/O error on vda1
> [ 35.207384] end_request: I/O error, dev vda, sector 1575624
> [ 35.207384] Buffer I/O error on device vda1, logical block 196697
> [ 35.207384] lost page write due to I/O error on vda1
> check_for_daemon_cancellation_or_eof: 0x1786f80 g->state = 3, fd = 66
> child_cleanup: 0x1786f80: child process died
>
> I should probably note that this is being done over NFS mounted
> images. I'm fairly sure there aren't NFS problems though, as the NFS
> mounts are quite stable and otherwise seem to respond just fine
> against the same mounts at the same time this problem occurs.
>
> I'm hoping the above might trigger some ideas but I'm still working on
> trying to figure out the lack of verbose data to stderr otherwise.
There seem to be a number of different things going on, but I really
don't have enough detail to be able to fix this. This error seems to
be unrelated to the Python issues you were having before.
The I/O errors above would be because the underlying disk is somehow
read-only to qemu.
By this you mean the uid the process is running as and not the actual
'qemu' uid, right? Just making sure..
For NFS I guess this could be because of root_squash-ing.
Hmm, ok. I will keep plugging away and update the thread if I discover
something.
One thing that's curious is I've also played with just using
command-line `virt-X` and `guestfish` to upload new files to the same
images and haven't had the same write problems and/or process hangs.
Secondly, the changes *do* get written to the images so it's certainly
not a flat-out permission denied issue.
Anyway, thanks for the feedback.
TJ