Re: [RFC 0/3] block/file-posix: Work around XFS bug

[Alberto Garcia]

On Mon 04 Nov 2019 03:25:12 PM CET, Max Reitz wrote:
>>>>> So, it's obvious that c8bb23cbdbe32f5c326 is significant for 1M
>>>>> cluster-size, even on rotational disk, which means that previous
>>>>> assumption about calling handle_alloc_space() only for ssd is wrong,
>>>>> we need smarter heuristics..
>>>>>
>>>>> So, I'd prefer (1) or (2).
>>>
>>> OK.  I wonder whether that problem would go away with Berto’s subcluster
>>> series, though.
>> 
>> Catching up with this now. I was told about this last week at the KVM
>> Forum, but if the problems comes with the use of fallocate() and XFS,
>> the I don't think subclusters will solve it.
>> 
>> handle_alloc_space() is used to fill a cluster with zeroes when there's
>> COW, and that happens the same with subclusters, just at the subcluster
>> level instead of course.
>> 
>> What can happen, if the subcluster size matches the filesystem block
>> size, is that there's no need for any COW and therefore the bug is never
>> triggered. But that's not quite the same as a fix :-)
>
> No, what I meant was that the original problem that led to c8bb23cbdbe
> would go away.

Ah, right. Not quite, according to my numbers:

|--------------+----------------+-----------------+-------------|
| Cluster size | subclusters=on | subclusters=off | fallocate() |
|--------------+----------------+-----------------+-------------|
|       256 KB |     10182 IOPS |        966 IOPS |  14007 IOPS |
|       512 KB |      7919 IOPS |        563 IOPS |  13442 IOPS |
|      1024 KB |      5050 IOPS |        465 IOPS |  13887 IOPS |
|      2048 KB |      2465 IOPS |        271 IOPS |  13885 IOPS |
|--------------+----------------+-----------------+-------------|

There's obviously no backing image, and only the last column uses
handle_alloc_space() / fallocate().

Berto