From patchwork Tue Aug 15 10:19:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Tremer X-Patchwork-Id: 7090 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4RQ6hF4CB4z3wlH for ; Tue, 15 Aug 2023 10:19:41 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4RQ6hC0V71z1CQ; Tue, 15 Aug 2023 10:19:39 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4RQ6hB6sfLz2ylN; Tue, 15 Aug 2023 10:19:38 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4RQ6hB565Gz2xY7 for ; Tue, 15 Aug 2023 10:19:38 +0000 (UTC) Received: from michael.haj.ipfire.org (michael.haj.ipfire.org [172.28.1.242]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384 client-signature ECDSA (secp384r1) client-digest SHA384) (Client CN "michael.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4RQ6hB1Yy5z1MK; Tue, 15 Aug 2023 10:19:38 +0000 (UTC) Received: by michael.haj.ipfire.org (Postfix, from userid 0) id 4RQ6h950JYzTgF9; Tue, 15 Aug 2023 10:19:37 +0000 (UTC) From: Michael Tremer To: development@lists.ipfire.org Subject: [PATCH 2/3] mountfs: Remove excessive sync-ing before umount Date: Tue, 15 Aug 2023 10:19:35 +0000 Message-Id: <20230815101936.261078-2-michael.tremer@ipfire.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230815101936.261078-1-michael.tremer@ipfire.org> References: <20230815101936.261078-1-michael.tremer@ipfire.org> MIME-Version: 1.0 X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Michael Tremer Errors-To: development-bounces@lists.ipfire.org Sender: "Development" The system should perform all write operations when sync is called and only return when the write queues are empty. There is no additional benefit for calling sync again as the buffers should be empty. If data is still being lost, then that is a bug in either the storage device or driver. As the (re-)boot process is already so slow, I would like to get rid of any unnecessary delays. Signed-off-by: Michael Tremer --- src/initscripts/system/mountfs | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/initscripts/system/mountfs b/src/initscripts/system/mountfs index 2e2ff0b5b..8975eb02c 100644 --- a/src/initscripts/system/mountfs +++ b/src/initscripts/system/mountfs @@ -45,9 +45,7 @@ case "${1}" in stop) boot_mesg "Syncing discs..." - sync && sync - sleep 2 - sync && sync + sync evaluate_retval # ExtraHD