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