From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (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 finch.gentoo.org (Postfix) with ESMTPS id 0A54F158086 for ; Mon, 13 Dec 2021 22:26:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 505BC2BC057; Mon, 13 Dec 2021 22:26:16 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2ABB72BC010 for ; Mon, 13 Dec 2021 22:26:12 +0000 (UTC) Received: from host81-132-12-162.range81-132.btcentralplus.com ([81.132.12.162] helo=[192.168.1.218]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1mwtlp-0005IE-FN for gentoo-user@lists.gentoo.org; Mon, 13 Dec 2021 22:26:10 +0000 Message-ID: Date: Mon, 13 Dec 2021 22:26:09 +0000 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [gentoo-user] Bug in run-crons? Content-Language: en-US To: gentoo-user@lists.gentoo.org References: <0fa56046dbf46a92723f588f2b458deb53771c5c.camel@gentoo.org> <1e7ebc2410db0e42c7692f951c6614061d0004bb.camel@gentoo.org> From: Wols Lists In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 8628b2b5-7c8e-48a7-b83d-972933914156 X-Archives-Hash: 1386509366a2ed6863961bb803ebd176 On 13/12/2021 22:03, Frank Steinmetzger wrote: >> If they are involved multiple times >> with the default options I think any attempt to scrub something that >> is already being scrubbed is just a no-op. Obviously if you don't >> want all that IO during the day you'll have to do something more >> clever - you can instruct it to pause and resume so you could have a >> couple of crontab entries and scripts to do just that. > Or, since I am the only user of that system, I could go back to my previous > way: just run the scrub manually every other month or so before I go to bed. > Because then I know that nothing will interfere with it and it won’t > interfere with anything else. Yup. I was thinking that. The problem with scrubs et al auto-resuming or firing at boot is that disk i/o is then knackered for ages, and interferes with whatever it is you're actually trying to do :-) Cheers, Wol