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 400CD70011 for ; Thu, 24 Jun 2021 11:24:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3B60E83CD for ; Thu, 24 Jun 2021 11:23:30 +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 A853983C2 for ; Thu, 24 Jun 2021 11:23:29 +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 7B20142BCC for ; Thu, 24 Jun 2021 11:23:29 +0200 (CEST) Date: Thu, 24 Jun 2021 11:23:22 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion , Thomas Lamprecht Cc: Wolfgang Bumiller References: <20210624072920.43336-1-w.bumiller@proxmox.com> <1624521156.jnauh4rg8d.astroid@nora.none> <9da93aae-c870-2b31-c13d-1e633f0e3354@proxmox.com> In-Reply-To: <9da93aae-c870-2b31-c13d-1e633f0e3354@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <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.381 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 URI_NOVOWEL 0.5 URI hostname has long non-vowel sequence 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:24:00 -0000 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: >>> Signed-off-by: Wolfgang Bumiller >>> --- >>> PVE/Storage/BTRFSPlugin.pm | 30 ++++++++++++++++++++++++++++++ >>> 1 file changed, 30 insertions(+) >>> >>> diff --git a/PVE/Storage/BTRFSPlugin.pm b/PVE/Storage/BTRFSPlugin.pm >>> index 133edc6..0e111a0 100644 >>> --- a/PVE/Storage/BTRFSPlugin.pm >>> +++ b/PVE/Storage/BTRFSPlugin.pm >>> @@ -20,6 +20,7 @@ use constant { >>> FS_NOCOW_FL =3D> 0x00800000, >>> FS_IOC_GETFLAGS =3D> 0x40086602, >>> FS_IOC_SETFLAGS =3D> 0x80086601, >>> + BTRFS_MAGIC =3D> 0x9123683e, >>> }; >>> =20 >>> # Configuration (similar to DirPlugin) >>> @@ -89,8 +90,29 @@ sub check_config { >>> return PVE::Storage::DirPlugin::check_config($self, $sectionId, $c= onfig, $create, $skipSchemaCheck); >>> } >>> =20 >>> +my sub getfsmagic($) { >>> + my ($path) =3D @_; >>> + # The field type sizes in `struct statfs` are defined in a rather = annoying way, and we only >>> + # need the first field, which is a `long` for our supported platfo= rms. >>> + # Should be moved to pve-rs, so this can be the problem of the `li= bc` crate ;-) >>> + # Just round up and extract what we need: >>> + my $buf =3D pack('x160'); >>> + if (0 !=3D syscall(&PVE::Syscall::SYS_statfs, $path, $buf)) { >>> + die "statfs on '$path' failed - $!\n"; >>> + } >>> + >>> + return unpack('L!', $buf); >>> +} >>> + >>> +my sub assert_btrfs($) { >>> + my ($path) =3D @_; >>> + die "'$path' is not a btrfs file system\n" >>> + if getfsmagic($path) !=3D BTRFS_MAGIC; >>> +} >>> + >>> sub activate_storage { >>> my ($class, $storeid, $scfg, $cache) =3D @_; >>> + assert_btrfs($scfg->{path}); >>> return PVE::Storage::DirPlugin::activate_storage($class, $storeid,= $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.. >>=20 >=20 > But then we create already the sub-directories in DirPlugin's SUPER->acti= vate_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.. maybe if is_mountpoint check that mountpoint // path with DirPlugin::path_is_moun= ted && btrfs then call activate_storage from dir plugin then check $path is btrfs 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=20 we pull in the mkdir $path handling into the BTRFSPlugin, then=20 everything would be handled (and only the subdir creation is delegate to=20 the DirPlugin..)