From: Lorenz Stechauner <l.stechauner@proxmox.com>
To: Fabian Ebner <f.ebner@proxmox.com>,
pve-devel@lists.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:26:17 +0200 [thread overview]
Message-ID: <a00d1c5f-5cd4-07af-66e1-d8cf6f42c613@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).
makes sense, I got a bit confused by the rbd stuff. Then I won't update
the patch to use 'sparse' :)
>
>>>
>>>> Le lundi 06 septembre 2021 à 15:15 +0200, Lorenz Stechauner a écrit :
>>>>> the plugins for file based storages
>>>>> * BTRFS
>>>>> * CIFS
>>>>> * Dir
>>>>> * Glusterfs
>>>>> * NFS
>>>>> now allow the option 'preallocation'.
>>>>>
>>>>> 'preallocation' can have four values:
>>>>> * default
>>>>> * off
>>>>> * metadata
>>>>> * falloc
>>>>> * full
>>>>> see man pages for `qemu-img` for what these mean exactly. [0]
>>>>>
>>>>> the defualt value was chosen to be
>>>>> * qcow2: metadata (as previously)
>>>>> * raw: off (I was unable to find any documentation on this, so
>>>>> could only test this and found, that 'off' was the most
>>>>> fitting.)
>>>>>
>>>>> when using 'metadata' as preallocation mode, for raw images 'off'
>>>>> is used.
>>>>>
>>>>> [0]
>>>>> https://qemu.readthedocs.io/en/latest/system/images.html#disk-image-file-formats
>>>>>
>>>>>
>>>>> Signed-off-by: Lorenz Stechauner <l.stechauner@proxmox.com>
next prev parent reply other threads:[~2021-09-09 12:26 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 [this message]
2021-09-09 12:28 ` Thomas Lamprecht
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=a00d1c5f-5cd4-07af-66e1-d8cf6f42c613@proxmox.com \
--to=l.stechauner@proxmox.com \
--cc=aderumier@odiso.com \
--cc=f.ebner@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