On 09.09.21 14:04, Fabian Ebner wrote:
> Am 09.09.21 um 13:11 schrieb Lorenz Stechauner:
>>
>> On 09.09.21 12:25, Fabian Ebner wrote:
>>> Am 08.09.21 um 10:11 schrieb alexandre derumier:
>>>> Hi,
>>>> it can be done too with ceph rbd with "rbd create ... –thick-provision"
>>>>
>>>
>>> Hi,
>>> there also is the 'sparse' storage config option (currently only used for 
>>> ZFS plugins). If there is only thick or thin, re-using that one is probably 
>>> nicer, because the newly proposed preallocation option seems to be closely 
>>> tied to qemu-img.
>>
>> Sounds like a good idea. I doubt, that anyone would use full prellocation 
>> anyway, so simply using 'sparse' for prealloc=off and default remains 
>> prealloc=metadata sounds good.
>>
> 
> I actually only meant re-using 'sparse' for the RBD use case. But yes, it 
> seems like re-using it for the qemu-img use case would be enough to fix the 
> bug too. It might be a bit confusing though, because when sparse is not set, 
> the images would still be mostly sparse (except for metadata).

Yeah, I'm not sure that just deriving all from the sparse storage option would
be good UX - I think it should be per creation and if we want to expand the 
scope
of such a value we should rather see it as fallback.

But IMO this is a bit of an edge case anyway, so I'd not rush the latter without
user demand.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to