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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.