From nobody Mon Jan 23 16:49:42 2023
X-Original-To: freebsd-stable@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 4P0x0h0GGFz30whF
	for <freebsd-stable@mlmmj.nyi.freebsd.org>; Mon, 23 Jan 2023 16:49:56 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.123])
	(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)
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4P0x0g4lQJz40Kf
	for <freebsd-stable@freebsd.org>; Mon, 23 Jan 2023 16:49:55 +0000 (UTC)
	(envelope-from paul@gromit.dlib.vt.edu)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (unknown [IPv6:2001:470:e15b:23::23])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D1E892831B;
	Mon, 23 Jan 2023 11:49:43 -0500 (EST)
Content-Type: text/plain;
	charset=us-ascii
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/freebsd-stable
List-Help: <mailto:stable+help@freebsd.org>
List-Post: <mailto:stable@freebsd.org>
List-Subscribe: <mailto:stable+subscribe@freebsd.org>
List-Unsubscribe: <mailto:stable+unsubscribe@freebsd.org>
Sender: owner-freebsd-stable@freebsd.org
X-BeenThere: freebsd-stable@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: close() taking minutes (ZFS related)
From: Paul Mather <paul@gromit.dlib.vt.edu>
In-Reply-To: <Y85nY7AgWMvhWruF@disp.intra.daemon.contact>
Date: Mon, 23 Jan 2023 11:49:42 -0500
Cc: Mateusz Guzik <mjguzik@gmail.com>,
 freebsd-stable@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <C558EB67-330F-48AE-A251-E244089311CB@gromit.dlib.vt.edu>
References: <Y8oUemqHiPilKCK7@disp.intra.daemon.contact>
 <CAGudoHE4Sx_KY1vAsF1r8zXW6Y3vA4odRj6=bfm0fmLXFcVN9g@mail.gmail.com>
 <Y8qknwgR4quVXxay@disp.intra.daemon.contact>
 <CAGudoHH_ZP9+dZHb=6y10urYcYCwjdE1qOS2T6n4ennOSzVJ_A@mail.gmail.com>
 <Y85nY7AgWMvhWruF@disp.intra.daemon.contact>
To: Peter <pmc@citylink.dinoex.sub.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-Rspamd-Queue-Id: 4P0x0g4lQJz40Kf
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-ThisMailContainsUnwantedMimeParts: N

On Jan 23, 2023, at 5:54 AM, Peter <pmc@citylink.dinoex.sub.org> wrote:

> It seems I have found the reason for the strange behaviour: it is
> dedup.
>=20
> The pool is configured to use dedup, because it carries all my jail OS
> installation, which are very similar. But dedup makes no sense on
> database filesets, and apparently it has very bad effects on real
> workload: it creates immense write-amplification (about factor 4)
> and probably other bad effects (memory is not the issue here).
>=20
> I don't think it should lockdown the entire pool, but it is
> understandable that it creates a logical relation between the
> different filesets.


Note that "dedup" is a fileset-level property and so if the database =
filesets are poor candidates for deduping you should be able to set =
dedup to "off" for them to mitigate their bad impact on the system.

Even though dedup is a fileset-level property, enabling dedup on any =
fileset can have major impact system-wide (due to large resource =
consumption) and so should be done with due diligence.

Cheers,

Paul.