Am 11.06.2018 um 16:04 schrieb Max Reitz:
> On 2018-06-11 15:59, Peter Lieven wrote:
>> Am 11.06.2018 um 15:30 schrieb Max Reitz:
>>> On 2018-06-07 14:46, Peter Lieven wrote:
We currently don't enforce that the sparse segments we detect during
convert are
aligned. This leads to unnec
Am 11.06.2018 um 16:04 schrieb Max Reitz:
On 2018-06-11 15:59, Peter Lieven wrote:
Am 11.06.2018 um 15:30 schrieb Max Reitz:
On 2018-06-07 14:46, Peter Lieven wrote:
We currently don't enforce that the sparse segments we detect during
convert are
aligned. This leads to unnecessary and costly r
On 2018-06-11 15:59, Peter Lieven wrote:
> Am 11.06.2018 um 15:30 schrieb Max Reitz:
>> On 2018-06-07 14:46, Peter Lieven wrote:
>>> We currently don't enforce that the sparse segments we detect during
>>> convert are
>>> aligned. This leads to unnecessary and costly read-modify-write
>>> cycles ei
Am 11.06.2018 um 15:30 schrieb Max Reitz:
On 2018-06-07 14:46, Peter Lieven wrote:
We currently don't enforce that the sparse segments we detect during convert are
aligned. This leads to unnecessary and costly read-modify-write cycles either
internally in Qemu or in the background on the storage
On 2018-06-07 14:46, Peter Lieven wrote:
> We currently don't enforce that the sparse segments we detect during convert
> are
> aligned. This leads to unnecessary and costly read-modify-write cycles either
> internally in Qemu or in the background on the storage device as nearly all
> modern files
We currently don't enforce that the sparse segments we detect during convert are
aligned. This leads to unnecessary and costly read-modify-write cycles either
internally in Qemu or in the background on the storage device as nearly all
modern filesystems or hardware has a 4k alignment internally.
A