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.csa...@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 {
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
