From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 092EE7002C for ; Thu, 24 Jun 2021 11:27:25 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 00DE98551 for ; Thu, 24 Jun 2021 11:27:25 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 85401853B for ; Thu, 24 Jun 2021 11:27:24 +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 5271A46798 for ; Thu, 24 Jun 2021 11:27:24 +0200 (CEST) Message-ID: <1522a367-35fe-e7ba-a03b-9881d24c1dd7@proxmox.com> Date: Thu, 24 Jun 2021 11:27:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Thunderbird/90.0 Content-Language: en-US To: Proxmox VE development discussion , =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= Cc: Wolfgang Bumiller References: <20210624072920.43336-1-w.bumiller@proxmox.com> <1624521156.jnauh4rg8d.astroid@nora.none> <9da93aae-c870-2b31-c13d-1e633f0e3354@proxmox.com> <1624526230.jg5pbz96o8.astroid@nora.none> From: Thomas Lamprecht In-Reply-To: <1624526230.jg5pbz96o8.astroid@nora.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.634 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH storage] btrfs: check for btrfs in on_add_hook and activate X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 09:27:25 -0000 On 24.06.21 11:23, Fabian Gr=C3=BCnbichler wrote: > On June 24, 2021 11:10 am, Thomas Lamprecht wrote: >> On 24.06.21 09:56, Fabian Gr=C3=BCnbichler wrote: >>> On June 24, 2021 9:29 am, Wolfgang Bumiller wrote: >>>> sub activate_storage { >>>> my ($class, $storeid, $scfg, $cache) =3D @_; >>>> + assert_btrfs($scfg->{path}); >>>> return PVE::Storage::DirPlugin::activate_storage($class, $store= id, $scfg, $cache); >>> shouldn't this be the other way round? first check for things like=20 >>> is_mountpoint, then whether btrfs is there.. makes for less confusing= =20 >>> error message at least.. >>> >> >> But then we create already the sub-directories in DirPlugin's SUPER->a= ctivate_storage call >> to the base plugin one and leave that stuff over when the assert fails= ? >> >=20 > true. but OTOH, we do support dir storages where $path does not exist=20 > yet before the first activation.. >=20 > maybe >=20 > if is_mountpoint check that mountpoint // path with DirPlugin::path_is_= mounted && btrfs >=20 > then call activate_storage from dir plugin >=20 > then check $path is btrfs >=20 > most setups should have is_mountpoint set (except maybe / on btrfs with= =20 > no separate "data" filesystem..), so this should handle most of it. if = > we pull in the mkdir $path handling into the BTRFSPlugin, then=20 > everything would be handled (and only the subdir creation is delegate t= o=20 > the DirPlugin..) >=20 I just duplicated the DirPlugin activate storage, could be factored out m= aybe but for now I prefer it as is, using actual plugin methods from other plugins= feels always a bit weird and risky, as on the use-site one is seldom aware of t= hat when changing things there, risking breakage - so in the longer term I'd like = that the more generic stuff moves to a "static" helper module, not having a export= -base.