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 57FB28BF5A for ; Fri, 28 Oct 2022 13:24:35 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 34A5D1A358 for ; Fri, 28 Oct 2022 13:24:35 +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 for ; Fri, 28 Oct 2022 13:24:34 +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 70ACE44AE6 for ; Fri, 28 Oct 2022 13:24:33 +0200 (CEST) Message-ID: Date: Fri, 28 Oct 2022 13:24:31 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Thunderbird/107.0 Content-Language: en-GB To: Proxmox Backup Server development discussion , Dominik Csapak References: <20221028073449.1120342-1-d.csapak@proxmox.com> <20221028073449.1120342-4-d.csapak@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20221028073449.1120342-4-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.034 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: [pbs-devel] [PATCH proxmox-backup v4 3/3] datastore: make 'filesystem' the default sync-level X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2022 11:24:35 -0000 Updated stats would be nice, maybe with the following parings: (v)Disk backed by * nvme * spinner FS of: - ext4 - XFS - ZFS Each combined with each disk backing type and current newest default software (i.e. kernel 5.15). Additionally maybe also NFS or CIFS. Those results would then maybe again nice to have in the commit message. Would help to find a more clear verdict, as currently I'm close to, but not yet fully 100% sure if we just want to switch plainly, maybe making it easier to change by adding it in the web interface, to the datastore options tab and emphasizing it in the upcoming 2.3 changelog could be already enough; depending on the numbers. On 28/10/2022 09:34, Dominik Csapak wrote: > Signed-off-by: Dominik Csapak > --- > docs/storage.rst | 4 ++-- > pbs-api-types/src/datastore.rs | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/docs/storage.rst b/docs/storage.rst > index c4e44c72..d61c3a40 100644 > --- a/docs/storage.rst > +++ b/docs/storage.rst > @@ -344,13 +344,13 @@ and only available on the CLI: > the crash resistance of backups in case of a powerloss or hard shutoff. > There are currently three levels: > > - - `none` (default): Does not do any syncing when writing chunks. This is fast > + - `none` : Does not do any syncing when writing chunks. This is fast > and normally OK, since the kernel eventually flushes writes onto the disk. > The kernel sysctls `dirty_expire_centisecs` and `dirty_writeback_centisecs` > are used to tune that behaviour, while the default is to flush old data > after ~30s. > > - - `filesystem` : This triggers a ``syncfs(2)`` after a backup, but before > + - `filesystem` (default): This triggers a ``syncfs(2)`` after a backup, but before > the task returns `OK`. This way it is ensured that the written backups > are on disk. This is a good balance between speed and consistency. > Note that the underlying storage device still needs to protect itself against > diff --git a/pbs-api-types/src/datastore.rs b/pbs-api-types/src/datastore.rs > index 4c9eda2f..ff8fe55f 100644 > --- a/pbs-api-types/src/datastore.rs > +++ b/pbs-api-types/src/datastore.rs > @@ -181,7 +181,6 @@ pub enum DatastoreFSyncLevel { > /// which reduces IO pressure. > /// But it may cause losing data on powerloss or system crash without any uninterruptible power > /// supply. > - #[default] > None, > /// Triggers a fsync after writing any chunk on the datastore. While this can slow down > /// backups significantly, depending on the underlying file system and storage used, it > @@ -196,6 +195,7 @@ pub enum DatastoreFSyncLevel { > /// Depending on the setup, it might have a negative impact on unrelated write operations > /// of the underlying filesystem, but it is generally a good compromise between performance > /// and consitency. > + #[default] > Filesystem, > } >