From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Fabian Ebner <f.ebner@proxmox.com>,
Lorenz Stechauner <l.stechauner@proxmox.com>,
aderumier@odiso.com
Subject: Re: [pve-devel] [PATCH storage 1/1] fix #3580: plugins: make preallocation mode selectable for qcow2 and raw images
Date: Thu, 9 Sep 2021 14:28:40 +0200 [thread overview]
Message-ID: <79abd2d8-3e4d-1b2f-0630-abbc5f5a4594@proxmox.com> (raw)
In-Reply-To: <b7e0cac5-696e-e4fc-8bf0-5d0d98f395c6@proxmox.com>
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.
next prev parent reply other threads:[~2021-09-09 12:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-06 13:15 [pve-devel] [PATCH-SERIES storage/manager] fix #3580: " Lorenz Stechauner
2021-09-06 13:15 ` [pve-devel] [PATCH storage 1/1] fix #3580: plugins: " Lorenz Stechauner
2021-09-08 8:11 ` alexandre derumier
2021-09-09 10:25 ` Fabian Ebner
2021-09-09 11:11 ` Lorenz Stechauner
2021-09-09 12:04 ` Fabian Ebner
2021-09-09 12:26 ` Lorenz Stechauner
2021-09-09 12:28 ` Thomas Lamprecht [this message]
2021-09-14 9:44 ` Fabian Ebner
2021-09-06 13:15 ` [pve-devel] [PATCH manager 1/2] ui: add PreallocationSelector Lorenz Stechauner
2021-09-06 13:15 ` [pve-devel] [PATCH manager 2/2] fix 3850: ui: storage: using PreallocationSelector for file based storage types Lorenz Stechauner
2021-09-14 9:55 ` Fabian Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79abd2d8-3e4d-1b2f-0630-abbc5f5a4594@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=aderumier@odiso.com \
--cc=f.ebner@proxmox.com \
--cc=l.stechauner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox