[pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Dominik Csapak]

this allows setting notes+protected for backups on btrfs

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 PVE/Storage/BTRFSPlugin.pm | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm
index be613f4..dd5f139 100644
--- a/PVE/Storage/BTRFSPlugin.pm
+++ b/PVE/Storage/BTRFSPlugin.pm
@@ -138,9 +138,25 @@ sub status {
     return PVE::Storage::DirPlugin::status($class, $storeid, $scfg, $cache);
 }
 
-# TODO: sub get_volume_attribute {}
+# FIXME remove on the next APIAGE reset.
+# Deprecated, use get_volume_attribute instead.
+sub get_volume_notes {
+    return PVE::Storage::DirPlugin::get_volume_notes(@_);
+}
+
+# FIXME remove on the next APIAGE reset.
+# Deprecated, use update_volume_attribute instead.
+sub update_volume_notes {
+    return PVE::Storage::DirPlugin::update_volume_notes( @_);
+}
 
-# TODO: sub update_volume_attribute {}
+sub get_volume_attribute {
+    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
+}
+
+sub update_volume_attribute {
+    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
+}
 
 # croak would not include the caller from within this module
 sub __error {
-- 
2.30.2

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Thomas Lamprecht]

Am 4/29/22 um 12:00 schrieb Dominik Csapak:
> this allows setting notes+protected for backups on btrfs
> 
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
>  PVE/Storage/BTRFSPlugin.pm | 20 ++++++++++++++++++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm
> index be613f4..dd5f139 100644
> --- a/PVE/Storage/BTRFSPlugin.pm
> +++ b/PVE/Storage/BTRFSPlugin.pm
> @@ -138,9 +138,25 @@ sub status {
>      return PVE::Storage::DirPlugin::status($class, $storeid, $scfg, $cache);
>  }
>  
> -# TODO: sub get_volume_attribute {}
> +# FIXME remove on the next APIAGE reset.
> +# Deprecated, use get_volume_attribute instead.
> +sub get_volume_notes {
> +    return PVE::Storage::DirPlugin::get_volume_notes(@_);
> +}
> +
> +# FIXME remove on the next APIAGE reset.
> +# Deprecated, use update_volume_attribute instead.
> +sub update_volume_notes {
> +    return PVE::Storage::DirPlugin::update_volume_notes( @_);
> +}

makes no sense to add these? they are deprecated and unused anyway

>  
> -# TODO: sub update_volume_attribute {}
> +sub get_volume_attribute {
> +    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
> +}
> +
> +sub update_volume_attribute {
> +    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
> +}

This is so trivial that I'm wondering if Wolfgang had a reason to not do it for the
original get_volume_notes that was there long before the BTRFS plugin got added..

>  
>  # croak would not include the caller from within this module
>  sub __error {

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Dominik Csapak]

On 5/2/22 08:36, Thomas Lamprecht wrote:
> Am 4/29/22 um 12:00 schrieb Dominik Csapak:
>> this allows setting notes+protected for backups on btrfs
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   PVE/Storage/BTRFSPlugin.pm | 20 ++++++++++++++++++--
>>   1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm
>> index be613f4..dd5f139 100644
>> --- a/PVE/Storage/BTRFSPlugin.pm
>> +++ b/PVE/Storage/BTRFSPlugin.pm
>> @@ -138,9 +138,25 @@ sub status {
>>       return PVE::Storage::DirPlugin::status($class, $storeid, $scfg, $cache);
>>   }
>>   
>> -# TODO: sub get_volume_attribute {}
>> +# FIXME remove on the next APIAGE reset.
>> +# Deprecated, use get_volume_attribute instead.
>> +sub get_volume_notes {
>> +    return PVE::Storage::DirPlugin::get_volume_notes(@_);
>> +}
>> +
>> +# FIXME remove on the next APIAGE reset.
>> +# Deprecated, use update_volume_attribute instead.
>> +sub update_volume_notes {
>> +    return PVE::Storage::DirPlugin::update_volume_notes( @_);
>> +}
> 
> makes no sense to add these? they are deprecated and unused anyway

no actually, the DirPlugin implementation calls
$class->get_volume_notes for now, so it would try to call the
BtrfsPlugin version of those which inherits from Plugin which dies in those...
(CephFs/CIFS/NFS actually do the same as i did here)

i guess we could do (untested)
--8<--
shift @_; # discard class
PVE::Storage::DirPlugin->update_volume_notes(@_);
-->8--

not sure if thats a good idea though

we could also factor out the get/update_volume_notes impl in DirPlugin
and call it from both paths? then we'd not have to implement
the _notes subs here

> 
>>   
>> -# TODO: sub update_volume_attribute {}
>> +sub get_volume_attribute {
>> +    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
>> +}
>> +
>> +sub update_volume_attribute {
>> +    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
>> +}
> 
> This is so trivial that I'm wondering if Wolfgang had a reason to not do it for the
> original get_volume_notes that was there long before the BTRFS plugin got added..

i mean it's possible, but idk how else you'd implement it? notes & protected
are only files where we read/write the content or test the existance?

we could probably do something btrfs specific, but is it worth that?

> 
>>   
>>   # croak would not include the caller from within this module
>>   sub __error {
> 

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Dominik Csapak]

>>> +    return PVE::Storage::DirPlugin::update_volume_notes( @_);
>>> +}
>>
>> makes no sense to add these? they are deprecated and unused anyway
> 
> no actually, the DirPlugin implementation calls
> $class->get_volume_notes for now, so it would try to call the
> BtrfsPlugin version of those which inherits from Plugin which dies in those...
> (CephFs/CIFS/NFS actually do the same as i did here)
> 
> i guess we could do (untested)
> --8<--
> shift @_; # discard class
> PVE::Storage::DirPlugin->update_volume_notes(@_);
> -->8--

i meant update_volume_attributes ofc

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Thomas Lamprecht]

Am 5/2/22 um 08:48 schrieb Dominik Csapak:
> On 5/2/22 08:36, Thomas Lamprecht wrote:
>> Am 4/29/22 um 12:00 schrieb Dominik Csapak:
>>> this allows setting notes+protected for backups on btrfs
>>>
>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>> ---
>>>   PVE/Storage/BTRFSPlugin.pm | 20 ++++++++++++++++++--
>>>   1 file changed, 18 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm
>>> index be613f4..dd5f139 100644
>>> --- a/PVE/Storage/BTRFSPlugin.pm
>>> +++ b/PVE/Storage/BTRFSPlugin.pm
>>> @@ -138,9 +138,25 @@ sub status {
>>>       return PVE::Storage::DirPlugin::status($class, $storeid, $scfg, $cache);
>>>   }
>>>   -# TODO: sub get_volume_attribute {}
>>> +# FIXME remove on the next APIAGE reset.
>>> +# Deprecated, use get_volume_attribute instead.
>>> +sub get_volume_notes {
>>> +    return PVE::Storage::DirPlugin::get_volume_notes(@_);
>>> +}
>>> +
>>> +# FIXME remove on the next APIAGE reset.
>>> +# Deprecated, use update_volume_attribute instead.
>>> +sub update_volume_notes {
>>> +    return PVE::Storage::DirPlugin::update_volume_notes( @_);
>>> +}
>>
>> makes no sense to add these? they are deprecated and unused anyway
> 
> no actually, the DirPlugin implementation calls
> $class->get_volume_notes for now, so it would try to call the
> BtrfsPlugin version of those which inherits from Plugin which dies in those...
> (CephFs/CIFS/NFS actually do the same as i did here)

such thing would be good things to include in the commit message ;-)

Anyhow, as removal of that method is planned anyhow the real fix would be to move
the implementation in update_volume_notes away from it, be it through inlining the
small logic or moving it to a new, private, helper.

> 
> i guess we could do (untested)
> --8<--
> shift @_; # discard class
> PVE::Storage::DirPlugin->update_volume_notes(@_);
> -->8--

most often it's way nicer to avoid the (@_) calls in general and do an explicit

my ($class, $...) = @_;
return foo($class, $...) # or whatever

anyway, allows to see the actual "signature" and makes things more explicit.


> 
> not sure if thats a good idea though
> 
> we could also factor out the get/update_volume_notes impl in DirPlugin
> and call it from both paths? then we'd not have to implement
> the _notes subs here
> 
>>
>>>   -# TODO: sub update_volume_attribute {}
>>> +sub get_volume_attribute {
>>> +    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
>>> +}
>>> +
>>> +sub update_volume_attribute {
>>> +    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
>>> +}
>>
>> This is so trivial that I'm wondering if Wolfgang had a reason to not do it for the
>> original get_volume_notes that was there long before the BTRFS plugin got added..
> 
> i mean it's possible, but idk how else you'd implement it? notes & protected
> are only files where we read/write the content or test the existance?
> 
> we could probably do something btrfs specific, but is it worth that?


as hinted, Wolfgang will be the one to answer the reason, even if it was just "forgot".
And yeah, it's IMO worth it to actually understand first why some seemingly trivial feature
was skipped before just doing something "blindly", seemingly obvious or not.

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Dominik Csapak]

On 5/2/22 09:04, Thomas Lamprecht wrote:
> Am 5/2/22 um 08:48 schrieb Dominik Csapak:
>> On 5/2/22 08:36, Thomas Lamprecht wrote:
>>> Am 4/29/22 um 12:00 schrieb Dominik Csapak:
>>>> this allows setting notes+protected for backups on btrfs
>>>>
>>>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>>>> ---
>>>>    PVE/Storage/BTRFSPlugin.pm | 20 ++++++++++++++++++--
>>>>    1 file changed, 18 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm
>>>> index be613f4..dd5f139 100644
>>>> --- a/PVE/Storage/BTRFSPlugin.pm
>>>> +++ b/PVE/Storage/BTRFSPlugin.pm
>>>> @@ -138,9 +138,25 @@ sub status {
>>>>        return PVE::Storage::DirPlugin::status($class, $storeid, $scfg, $cache);
>>>>    }
>>>>    -# TODO: sub get_volume_attribute {}
>>>> +# FIXME remove on the next APIAGE reset.
>>>> +# Deprecated, use get_volume_attribute instead.
>>>> +sub get_volume_notes {
>>>> +    return PVE::Storage::DirPlugin::get_volume_notes(@_);
>>>> +}
>>>> +
>>>> +# FIXME remove on the next APIAGE reset.
>>>> +# Deprecated, use update_volume_attribute instead.
>>>> +sub update_volume_notes {
>>>> +    return PVE::Storage::DirPlugin::update_volume_notes( @_);
>>>> +}
>>>
>>> makes no sense to add these? they are deprecated and unused anyway
>>
>> no actually, the DirPlugin implementation calls
>> $class->get_volume_notes for now, so it would try to call the
>> BtrfsPlugin version of those which inherits from Plugin which dies in those...
>> (CephFs/CIFS/NFS actually do the same as i did here)
> 
> such thing would be good things to include in the commit message ;-)
> 
> Anyhow, as removal of that method is planned anyhow the real fix would be to move
> the implementation in update_volume_notes away from it, be it through inlining the
> small logic or moving it to a new, private, helper.
> 
>>
>> i guess we could do (untested)
>> --8<--
>> shift @_; # discard class
>> PVE::Storage::DirPlugin->update_volume_notes(@_);
>> -->8--
> 
> most often it's way nicer to avoid the (@_) calls in general and do an explicit
> 
> my ($class, $...) = @_;
> return foo($class, $...) # or whatever
> 
> anyway, allows to see the actual "signature" and makes things more explicit.
> 
> 
>>
>> not sure if thats a good idea though
>>
>> we could also factor out the get/update_volume_notes impl in DirPlugin
>> and call it from both paths? then we'd not have to implement
>> the _notes subs here
>>
>>>
>>>>    -# TODO: sub update_volume_attribute {}
>>>> +sub get_volume_attribute {
>>>> +    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
>>>> +}
>>>> +
>>>> +sub update_volume_attribute {
>>>> +    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
>>>> +}
>>>
>>> This is so trivial that I'm wondering if Wolfgang had a reason to not do it for the
>>> original get_volume_notes that was there long before the BTRFS plugin got added..
>>
>> i mean it's possible, but idk how else you'd implement it? notes & protected
>> are only files where we read/write the content or test the existance?
>>
>> we could probably do something btrfs specific, but is it worth that?
> 
> 
> as hinted, Wolfgang will be the one to answer the reason, even if it was just "forgot".
> And yeah, it's IMO worth it to actually understand first why some seemingly trivial feature
> was skipped before just doing something "blindly", seemingly obvious or not.

makes sense, i just noticed because on content listing, the notes will already show up if
set this way because in the 'get_subdir_files' of Storage.pm we directly read the
notes file if it exists

Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin update/get_volume_attribute

[Wolfgang Bumiller]

> On 05/02/2022 9:20 AM Dominik Csapak <d.csapak@proxmox.com> wrote:
> 
>  
> On 5/2/22 09:04, Thomas Lamprecht wrote:
> > Am 5/2/22 um 08:48 schrieb Dominik Csapak:
> >> On 5/2/22 08:36, Thomas Lamprecht wrote:
> >>> Am 4/29/22 um 12:00 schrieb Dominik Csapak:
(...)
> >> not sure if thats a good idea though
> >>
> >> we could also factor out the get/update_volume_notes impl in DirPlugin
> >> and call it from both paths? then we'd not have to implement
> >> the _notes subs here
> >>
> >>>
> >>>>    -# TODO: sub update_volume_attribute {}
> >>>> +sub get_volume_attribute {
> >>>> +    return PVE::Storage::DirPlugin::get_volume_attribute(@_);
> >>>> +}
> >>>> +
> >>>> +sub update_volume_attribute {
> >>>> +    return PVE::Storage::DirPlugin::update_volume_attribute(@_);
> >>>> +}
> >>>
> >>> This is so trivial that I'm wondering if Wolfgang had a reason to not do it for the
> >>> original get_volume_notes that was there long before the BTRFS plugin got added..

Not that I remember. Most likely the reason was that initially I was playing with
different ways to place raw images (subvolume with a raw file with btrfs snapshots vs.
just the raw file with COW-copying for snapshots), where for some variants a different
file layout *could* be nice. But only in theory.

> >> i mean it's possible, but idk how else you'd implement it? notes & protected
> >> are only files where we read/write the content or test the existance?
> >>
> >> we could probably do something btrfs specific, but is it worth that?

Probably not. There isn't all that much available.

Given that path based storages apparently already expect this to work in a specific way
in some of the other storage functions outside the plugin (see Dominik's note about
`get_subdir_files`) I think this patch makes sense.

> > as hinted, Wolfgang will be the one to answer the reason, even if it was just "forgot".
> > And yeah, it's IMO worth it to actually understand first why some seemingly trivial feature
> > was skipped before just doing something "blindly", seemingly obvious or not.
> 
> makes sense, i just noticed because on content listing, the notes will already show up if
> set this way because in the 'get_subdir_files' of Storage.pm we directly read the
> notes file if it exists

^ So if we wanted to do anything else we'd probably need to override even more of
`Plugin` (iow. override code from the *grandparent* class) for not much gain.

So yeah, I think the patch is fine.