From: Alexandre arents <1912224@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1912224] Re: qemu may freeze during drive-mirroring on fragmented FS
Date: Fri, 22 Jan 2021 13:19:22 -0000 [thread overview]
Message-ID: <161132156293.20216.13851368057585754104.malone@wampee.canonical.com> (raw)
In-Reply-To: 161098039664.6686.1246044899603761821.malonedeb@wampee.canonical.com
Seems a regression introduce in commit : (2.7.0)
commit 0965a41e998ab820b5d660c8abfc8c819c97bc1b
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: Thu Jul 14 20:19:01 2016 +0300
mirror: double performance of the bulk stage if the disc is full
Mirror can do up to 16 in-flight requests, but actually on full copy
(the whole source disk is non-zero) in-flight is always 1. This happens
as the request is not limited in size: the data occupies maximum available
capacity of s->buf.
The patch limits the size of the request to some artificial constant
(1 Mb here), which is not that big or small. This effectively enables
back parallelism in mirror code as it was designed.
The result is important: the time to migrate 10 Gb disk is reduced from
~350 sec to 170 sec.
If I revert this commit on master on top of (fef80ea073c48) (minor
conflicts) issue disappears.
on a fragmented file (average size per exent 2125 KB) of 58GB:
upstream 207s (285 MB/s) instance is broken during mirroring
upstream with revert 225s (262 MB/s) instance is fine.
not fully tested, but the patch probably improve perf in other cases
(as disccuss in git message), maybe just need to improve to avoid the freeze?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1912224
Title:
qemu may freeze during drive-mirroring on fragmented FS
Status in QEMU:
New
Bug description:
We have odd behavior in operation where qemu freeze during long
seconds, We started an thread about that issue here:
https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg05623.html
It happens at least during openstack nova snapshot (qemu blockdev-mirror)
or live block migration(which include network copy of disk).
After further troubleshoots, it seems related to FS fragmentation on
host.
reproducible at least on:
Ubuntu 18.04.3/4.18.0-25-generic/qemu-4.0
Ubuntu 16.04.6/5.10.6/qemu-5.2.0-rc2
# Lets create a dedicated file system on a SSD/Nvme 60GB disk in my case:
$sudo mkfs.ext4 /dev/sda3
$sudo mount /dev/sda3 /mnt
$df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 59G 53M 56G 1% /mnt
#Create a fragmented disk on it using 2MB Chunks (about 30min):
$sudo python3 create_fragged_disk.py /mnt 2
Filling up FS by Creating chunks files in: /mnt/chunks
We are probably full as expected!!: [Errno 28] No space left on device
Creating fragged disk file: /mnt/disk
$ls -lhs
59G -rw-r--r-- 1 root root 59G Jan 15 14:08 /mnt/disk
$ sudo e4defrag -c /mnt/disk
Total/best extents 41971/30
Average size per extent 1466 KB
Fragmentation score 2
[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
This file (/mnt/disk) does not need defragmentation.
Done.
# the tool^^^ says it is not enough fragmented to be able to defrag.
#Inject an image on fragmented disk
sudo chown ubuntu /mnt/disk
wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img
qemu-img convert -O raw bionic-server-cloudimg-amd64.img \
bionic-server-cloudimg-amd64.img.raw
dd conv=notrunc iflag=fullblock if=bionic-server-cloudimg-amd64.img.raw \
of=/mnt/disk bs=1M
virt-customize -a /mnt/disk --root-password password:xxxx
# logon run console activity ex: ping -i 0.3 127.0.0.1
$qemu-system-x86_64 -m 2G -enable-kvm -nographic \
-chardev socket,id=test,path=/tmp/qmp-monitor,server,nowait \
-mon chardev=test,mode=control \
-drive file=/mnt/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none,discard\
-device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
$sync
$echo 3 | sudo tee -a /proc/sys/vm/drop_caches
#start drive-mirror via qmp on another SSD/nvme partition
nc -U /tmp/qmp-monitor
{"execute":"qmp_capabilities"}
{"execute":"drive-mirror","arguments":{"device":"drive-virtio-disk0","target":"/home/ubuntu/mirror","sync":"full","format":"qcow2"}}
^^^ qemu console may start to freeze at this step.
NOTE:
- smaller chunk sz and bigger disk size the worst it is.
In operation we also have issue on 400GB disk size with average 13MB/extent
- Reproducible also on xfs
Expected behavior:
-------------------
QEMU should remain steady, eventually only have decrease storage Performance
or mirroring, because of fragmented fs.
Observed behavior:
-------------------
Perf of mirroring is still quite good even on fragmented FS,
but it breaks qemu.
###################### create_fragged_disk.py ############
import sys
import os
import tempfile
import glob
import errno
MNT_DIR = sys.argv[1]
CHUNK_SZ_MB = int(sys.argv[2])
CHUNKS_DIR = MNT_DIR + '/chunks'
DISK_FILE = MNT_DIR + '/disk'
if not os.path.exists(CHUNKS_DIR):
os.makedirs(CHUNKS_DIR)
with open("/dev/urandom", "rb") as f_rand:
mb_rand=f_rand.read(1024 * 1024)
print("Filling up FS by Creating chunks files in: ",CHUNKS_DIR)
try:
while True:
tp = tempfile.NamedTemporaryFile(dir=CHUNKS_DIR,delete=False)
for x in range(CHUNK_SZ_MB):
tp.write(mb_rand)
os.fsync(tp)
tp.close()
except Exception as ex:
print("We are probably full as expected!!: ",ex)
chunks = glob.glob(CHUNKS_DIR + '/*')
print("Creating fragged disk file: ",DISK_FILE)
with open(DISK_FILE, "w+b") as f_disk:
for chunk in chunks:
try:
os.unlink(chunk)
for x in range(CHUNK_SZ_MB):
f_disk.write(mb_rand)
os.fsync(f_disk)
except IOError as ex:
if ex.errno != errno.ENOSPC:
raise
###########################################################3
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1912224/+subscriptions
next prev parent reply other threads:[~2021-01-22 13:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 14:33 [Bug 1912224] [NEW] qemu may freeze during drive-mirroring on fragmented FS Alexandre arents
2021-01-22 13:19 ` Alexandre arents [this message]
2021-01-25 9:34 ` [Bug 1912224] " Alexandre arents
2021-02-02 8:36 ` Alexandre arents
2021-02-03 10:02 ` Max Reitz
2021-02-03 12:24 ` Max Reitz
2021-02-03 14:21 ` Alexandre arents
2021-02-03 16:51 ` Max Reitz
2021-02-04 9:11 ` Alexandre arents
2021-02-10 13:36 ` Alexandre arents
2021-05-12 18:13 ` Thomas Huth
2021-05-14 19:29 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=161132156293.20216.13851368057585754104.malone@wampee.canonical.com \
--to=1912224@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).