> Stoiko Ivanov hat am 06.03.2024 14:24 CET geschrieben:
>
>
> see:
> https://github.com/openzfs/zfs/pull/15970
> https://github.com/openzfs/zfs/issues/15904
>
> for some additional background.
FWIW, this one got two approvals upstream in the meantime ;)
> Signed-off-by: Stoiko Ivanov
> ---
Am 04/03/2024 um 14:22 schrieb Christoph Heiss:
> It's mostly spelled BTRFS anyway in our documentation (and also the
> official casing AFAICS), so align a few instances where it spelled
> lowercase.
official spelling is really not consistent and includes at least btrfs,
BTRFS and Btrfs – but havi
Am 04/03/2024 um 14:22 schrieb Christoph Heiss:
> This paragraph as phrased in pmg-docs sounds better & reads easier, so
> apply it here too.
>
> Signed-off-by: Christoph Heiss
> ---
> getting-help.adoc | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
applied, thanks!
Am 04/03/2024 um 14:22 schrieb Christoph Heiss:
> Seems like a pretty sensible thing to do here too.
>
> Signed-off-by: Christoph Heiss
> ---
> asciidoc/asciidoc-pve.conf | 1 +
> getting-help.adoc | 2 +-
> pve-package-repos.adoc | 2 +-
> 3 files changed, 3 insertions(+), 2 deleti
Am 04/03/2024 um 14:22 schrieb Christoph Heiss:
> .. much like it many other repos.
>
> Signed-off-by: Christoph Heiss
> ---
> .gitignore | 3 +++
> 1 file changed, 3 insertions(+)
>
>
applied, thanks!
___
pve-devel mailing list
pve-devel@lists.pro
Am 01/03/2024 um 09:21 schrieb Dominik Csapak:
> The `_ZFS_over_iSCSI` wiki page is redirected to the legacy page
> (for historical reasons), but we want to link to the reference docs
> instead.
>
> for the wiki add the legacy link in a `see also` section, so users can
> still reach that page easi
Am 06.03.24 um 16:17 schrieb Maximiliano Sandoval:
> Fiona Ebner writes:
>
>> It might be cleaner to just use
>> emptyValue: 0,
>> in the field declaration like is already done for the "Target Size"
>> field. And the same issue is also present for the "Min. # of PGs" field,
>> right?
>
> Thanks
Fiona Ebner writes:
> It might be cleaner to just use
> emptyValue: 0,
> in the field declaration like is already done for the "Target Size"
> field. And the same issue is also present for the "Min. # of PGs" field,
> right?
Thanks for the emptyValue tip, I didn't know about it. Unfortunately, I
Am 06.03.24 um 15:14 schrieb Maximiliano Sandoval:
> If the pool has a target_size_ratio set it might be desirable to unset
> its value, e.g. if set by mistake on .mgr.
>
> Currently unsetting the value won't do anything in the web UI. With this
> patch it is set to zero, which the API correctly u
On 3/6/24 15:04, Fiona Ebner wrote:
Yes, but the question is what is worse: Needing to re-do the clone or
having the VM config on the wrong node?
To avoid that, I'd lean towards keeping the behavior of failing the task
if deactivating $newvollist fails. After all, at least in case of LVM
not
If the pool has a target_size_ratio set it might be desirable to unset
its value, e.g. if set by mistake on .mgr.
Currently unsetting the value won't do anything in the web UI. With this
patch it is set to zero, which the API correctly understands and unsets
it.
one can verify the value set using
When a template with disks on LVM is cloned to another node, the volumes
are first activated, then cloned and deactivated again after cloning.
However, if clones of this template are now created in parallel to other
nodes, it can happen that one of the tasks can no longer deactivate the
logical vo
Am 06.03.24 um 14:14 schrieb Friedrich Weber:
> On 06/03/2024 13:40, Fiona Ebner wrote:
>> Am 06.03.24 um 11:47 schrieb Hannes Duerr:
>>> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>>>
>>> if ($target) {
>>> # always deactivate volumes - avoid lvm LVs to be
changes from v1:
* add a fix for #5288 after Fiona managed to reproduce it and we saw it
was a known issue addressed by Fabian with a pull-request upstream
* add a bit more detail to the submodule-update commit-message
minimally tested in my virtual setup, additionally Fiona tested that the
fix
see:
https://github.com/openzfs/zfs/pull/15970
https://github.com/openzfs/zfs/issues/15904
for some additional background.
Signed-off-by: Stoiko Ivanov
---
...rectly-handle-partition-16-and-later.patch | 52 +++
debian/patches/series | 1 +
2 files chang
mostly support for newer kernel-versions, and fixes for the BRT bugs
discovered with 2.2.0 (BRT remains disabled by default).
The update contains a fix for CVE-2020-24370 in lua (which is present
in ZFS for channel-programs, which we do not use) - see:
https://github.com/openzfs/zfs/pull/15847 for
On 06/03/2024 13:40, Fiona Ebner wrote:
> Am 06.03.24 um 11:47 schrieb Hannes Duerr:
>> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>>
>> if ($target) {
>> # always deactivate volumes - avoid lvm LVs to be active on
>> several nodes
>> -PVE
Am 06.03.24 um 11:47 schrieb Hannes Duerr:
> @@ -3820,7 +3821,13 @@ __PACKAGE__->register_method({
>
> if ($target) {
> # always deactivate volumes - avoid lvm LVs to be active on
> several nodes
> - PVE::Storage::deactivate_volumes($storecfg, $vol
Am 06.03.24 um 12:37 schrieb Friedrich Weber:
> Thanks for tackling this! Can confirm this patch demotes the error to a
> warning and lets the qmclone task succeed (with a warning). GUI shows
> "Warnings: 1" and task log contains:
>
> can't deactivate LV '/dev/foobar/vm-100-disk-0': Logical volu
Thanks for tackling this! Can confirm this patch demotes the error to a
warning and lets the qmclone task succeed (with a warning). GUI shows
"Warnings: 1" and task log contains:
can't deactivate LV '/dev/foobar/vm-100-disk-0': Logical volume
foobar/vm-100-disk-0 in use.
WARN: volume deactivatio
applied, thanks
___
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
When a template with disks on LVM is cloned to another node, the storage
is first activated, then cloned and deactivated again after cloning.
However, if clones of this template are now created in parellel to other
nodes, it can happen that one of the tasks can no longer deactivate the
logical vol
--- Begin Message ---
On Tue, Mar 05, 2024 at 01:13:08PM +0100, Fabian Grünbichler wrote:
> I wonder whether the following wouldn't also work?
>
> - keep the volume name on the PVE side like the other storage plugins
> (which means - encode vital information about the volume there so that
> it's p
23 matches
Mail list logo
