[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-4.2 v2 3/3] block/file-posix: Let post-EOF fallocate seri
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [PATCH for-4.2 v2 3/3] block/file-posix: Let post-EOF fallocate serialize |
Date: |
Sat, 22 Aug 2020 20:03:58 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
01.11.2019 18:25, Max Reitz wrote:
The XFS kernel driver has a bug that may cause data corruption for qcow2
images as of qemu commit c8bb23cbdbe32f. We can work around it by
treating post-EOF fallocates as serializing up until infinity (INT64_MAX
in practice).
Hi! I'm doing some investigation, and here is an interesting result:
Consider the following test:
img=/ssd/x.qcow2; ./qemu-img create -f qcow2 $img 16G; ./qemu-img bench -c
50000 -d 64 -f qcow2 -o 1k -s 64k -t none -w $img
Bisecting results changes between 2.12 and 5.1, I found the following:
2.12: ~20s
....
c8bb23cbdbe32 "qcow2: skip writing zero buffers to empty COW areas" -> becomes
~12s [1]
....
292d06b925b27 "block/file-posix: Let post-EOF fallocate serialize" -> becomes
~9s [2]
....
v5.1 ~9s
And [1] is obvious, it is the main purpose of c8bb23cbdbe32. But [2] is a
surprise for me.. Any ideas?
===
just to check: staying at c8bb23cbdbe32 I revert c8bb23cbdbe32 and get again
~19.7s. So [2] doesn't substitute [1].
--
Best regards,
Vladimir
- Re: [PATCH for-4.2 v2 3/3] block/file-posix: Let post-EOF fallocate serialize,
Vladimir Sementsov-Ogievskiy <=