From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <w.bumiller@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 3A65F72F86
 for <pve-devel@lists.proxmox.com>; Wed, 25 May 2022 12:48:49 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 2A4802A2FD
 for <pve-devel@lists.proxmox.com>; Wed, 25 May 2022 12:48:49 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS id C56792A2F0
 for <pve-devel@lists.proxmox.com>; Wed, 25 May 2022 12:48:47 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 8EBFA4275E
 for <pve-devel@lists.proxmox.com>; Wed, 25 May 2022 12:48:41 +0200 (CEST)
Date: Wed, 25 May 2022 12:48:39 +0200 (CEST)
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 Dominik Csapak <d.csapak@proxmox.com>,
 Thomas Lamprecht <t.lamprecht@proxmox.com>
Message-ID: <513329947.1015.1653475719893@webmail.proxmox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.5-Rev43
X-Originating-Client: open-xchange-appsuite
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.329 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 T_SCC_BODY_TEXT_LINE    -0.01 -
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [storage.pm]
Subject: Re: [pve-devel] [PATCH storage] BTRFSPlugin: reuse DirPlugin
 update/get_volume_attribute
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 25 May 2022 10:48:49 -0000

> 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.