Re: disk monopolized?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On a related note, did the kernel devs ever fix the bug where high I/O would make the system basically unusable? This sounds a lot like that, but I thought stuff like blk-mq were supposed to fix it.

On Sun, Dec 11, 2016 at 1:13 PM, jd1008 <jd1008@xxxxxxxxx> wrote:


On 12/11/2016 06:08 AM, Tom Horsley wrote:
Last night I was "optimizing" a qcow2 virtual image
(after zero filling the free space), running (as root):

qemu-img convert -f qcow2 -O qcow2 old.img new.img

The copying and scanning for zero blocks pretty
much took over the disk. Anything else I tried to run
which needed access to something on that disk would
hang for minutes at a time before getting through.

Is that normal behavior? I thought folks were supposed
to take turns and play nice together :-).
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@lists.fedoraproject.org
So "qcow2 old.img" is on the file system you want other apps to access,
and so is  "new.img" ? this sounds like "as if" qemu-img wants to make sure
that the two images, old and new, will not be modified during the conversion
process. Since you ARE running as root, you have the privs to run the conversion
at a very high priority that, for most of the time, it is picked first off the run queue
and placed on cpu, and "might" even be inhibiting access to the filesystem hosting
the 2 images during the conversion.

Now this is all conjecture on my part as I have never used it.

Other issues might be
1. The drive is a very slow drive
     and/or
2. You do not have sufficient ram for buffering large amounts of data
    and/or
3. You do not have multiple cores for other threads to run on different cores.

One of the ways to really debug this is to scan the source code of qemu-img to
see what priority it tries to give itself, what read/write/ioctl operations it is performing
and look up the man pages on those operations to see if they are being performed
in a manner that the process (in the kernel) spins idly while waiting for the operation
to finish, and also scan the kernel to see if the huge FS spinlock is held during the entire
conversion operation.

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@lists.fedoraproject.org

_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]
  Powered by Linux