From nobody Sun Oct 16 16:48:39 2022 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr5gL539dz4fbm0 for ; Sun, 16 Oct 2022 16:49:02 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr5gK4YKwz3lsF for ; Sun, 16 Oct 2022 16:49:01 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5F454320051E for ; Sun, 16 Oct 2022 12:49:00 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Sun, 16 Oct 2022 12:49:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1665938939; x=1666025339; bh=fkN7O7Y3TS zFLLlmFGbwQkbhvA5J6y3HXW04Z1SDGsQ=; b=tQAb67sI987Jhvjq83fabkNrcl pUnJ36ouKH1HuRsOqt3uq/s1kxRggpkz+TeOvVSzDQy3JzJPoVzuuQoXaUITpO/F zgFpePIm1x4IEHDxq7I29x4ZxQhpJRpzyG8vRU7I433xThdh/27+CjeHlPyq7409 a8CP2x5ENPAy6zJrJpVe7gPXRwtE3yx/ijCXKO+iftUCWtoda9cen14Iv7VdGifO /T6AAWNTSTq/WNQkw0rCfdzGuA+1b03ZtYoKeELHgz3GOk5x/oXQKwGjkM178o7q juyI96r8bqDcVeF48DxegTgFZN19EBYfHQTeWIg22eTPIKIWNPvYUCMifnFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1665938939; x=1666025339; bh=fkN7O7Y3TSzFLLlmFGbwQkbhvA5J 6y3HXW04Z1SDGsQ=; b=ni81sWo2b5to8bYapM2ebtmaLpBudNSHm4msPraFTthX t5PwdWJCjDyKKWUQlBoqlY89V23xT0/Dt8OJod+fwfdwoHvrPan7Kf3ysYadu1WH vRH0OiSE29IL1/O8t2t0n6VQy1nn9rF3iQI6ViX0JtqF3zsbpXsdHmDqsfFSRsSU A8dVKFP6i0ldHy0SCiyv2tRVDvf3z2LgH/PHx2IuFbcSE6XvmqrQQvPdP0+QPgdW 5udt+VyorWWztx8jhJmk6RXc6tbbsb6zkHbJE8q08h1eyowpGUh2KEdH/oIO57/s hKXGdVtWifWiPOlsr4mtmPUrRvwvu3YoWTPhHORhTA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeekjedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggft rfgrthhtvghrnhepieetvdeuhedthedtvdfhuefhveehvdeiledvieffheevleehgeefud eljedukedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id C5A4A2A20079; Sun, 16 Oct 2022 12:48:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1047-g9e4af4ada4-fm-20221005.001-g9e4af4ad List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 16 Oct 2022 16:48:39 +0000 From: void To: freebsd-fs Subject: Re: zfs with operations like rm -rf takes a very long time recently Content-Type: text/plain X-Rspamd-Queue-Id: 4Mr5gK4YKwz3lsF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm3 header.b=tQAb67sI; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=ni81sWo2; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-4.55 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.964]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25:c]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from] X-ThisMailContainsUnwantedMimeParts: N Hi, On Sun, 16 Oct 2022, at 15:42, Mark Millard wrote: > The book is not explicit about RAM subsystem performance > tradeoffs for ZFS. One property of the RPi4B's is that they > have very small RAM caches and one core can saturate the > memory subsystem if the RAM caches are being fairly > ineffective overall. In such contexts, multi-core need not > cut the time things take. (But I've no clue how likely such > conditions would be for your context.) A cache-busting > access pattern over much more than 1 MiByte memory range > drops the RPi4B performance greatly compared to such an > access pattern fitting in a 1 MiByte or smaller range --no > matter if it is 1 core or more cores that is/are trying to > be active. That's interesting; i cant understand the system has been in use for 9 months or so without this performance penalty. The OS has been updated on the following timeline main-n258595-226e41467ee1 on 2022-10-13 main-n258157-f50274674eb on 2022-09-23 main-n257818-6f7bc8e7a3d on 2022-09-05 main-n257229-e9a2e4d1d28 on 2022-08-10 main-n255150-70910e4b55c on 2022-05-04 cleaning out /usr/obj and /var/cache/ccache/* is something i'll do periodically if what is required is a completely clean from-scratch build. On at least two of those occasions I'd be doing what I'm trying now. but only now this issue has arisen. Of course, it may very well be the hardware. But all the things i'd use to monitor it say it's all fine. would output of zfs-stats -a be of use? thanks,