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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D40237149D for <pve-devel@lists.proxmox.com>; Thu, 10 Jun 2021 15:00:01 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C12CF2FEA3 for <pve-devel@lists.proxmox.com>; Thu, 10 Jun 2021 14:59:31 +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 95E522FE95 for <pve-devel@lists.proxmox.com>; Thu, 10 Jun 2021 14:59:30 +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 660D746759 for <pve-devel@lists.proxmox.com>; Thu, 10 Jun 2021 14:59:30 +0200 (CEST) Date: Thu, 10 Jun 2021 14:59:29 +0200 From: Wolfgang Bumiller <w.bumiller@proxmox.com> To: Fabian =?utf-8?Q?Gr=C3=BCnbichler?= <f.gruenbichler@proxmox.com> Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Message-ID: <20210610125929.asaq3azdvadbi52f@wobu-vie.proxmox.com> References: <20210609131852.167416-1-w.bumiller@proxmox.com> <20210609131852.167416-4-w.bumiller@proxmox.com> <1623328690.owhbf7mh8s.astroid@nora.none> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1623328690.owhbf7mh8s.astroid@nora.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.881 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 Subject: Re: [pve-devel] [PATCH storage 2/4] add BTRFS storage plugin 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: Thu, 10 Jun 2021 13:00:01 -0000 On Thu, Jun 10, 2021 at 02:40:22PM +0200, Fabian Grünbichler wrote: > On June 9, 2021 3:18 pm, Wolfgang Bumiller wrote: > > This is mostly the same as a directory storage, with 2 major > > differences: > > > > * 'subvol' volumes are actual btrfs subvolumes and therefore > > allow snapshots > > * 'raw' files are placed *into* a subvolume and therefore > > also allow snapshots, the raw file for volume > > `btrstore:100/vm-100-disk-1.raw` can be found under > > `$path/images/100/vm-100-disk-1/disk.raw` > > * snapshots add an '@name' suffix to the subvolume's name, > > so snapshot 'foo' of the above would be found under > > `$path/images/100/vm-100-disk-1@foo/disk.raw` > > > > Note that qgroups aren't included in btrfs-send streams, > > therefore for now we will only be using *unsized* subvolumes > > for containers and place a regular raw+ext4 file for sized > > containers. > > We could extend the import/export stream format to include > > the information at the front (similar to how we do the > > "tar+size" format, but we need to include the size of all > > the contained snapshots as well, since they can technically > > change). (But before enabling quotas we should do some > > performance testing on bigger file systems with multiple > > snapshots as there are quite a few reports of the fs slowing > > down considerably in such scenarios). > > this should probably be mentioned prominently in the docs somewhere, > else it could cause quite some confusion. also is ext4 in raw image on > btrfs really faster than btrfs with quotas? Oo we really should do some > benchmarks first before going down either route.. I do also have an idea for a simple-enough & extendable import/export format change for also sending the quota info over the wire, so we can go either way. But yes, we definitely need to do some performance tests... And also watch btrfs-scrubs with quotas in use... ;-)