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
