Date: Mon, 23 Jan 2023 11:49:42 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Peter <pmc@citylink.dinoex.sub.org> Cc: Mateusz Guzik <mjguzik@gmail.com>, freebsd-stable@freebsd.org Subject: Re: close() taking minutes (ZFS related) Message-ID: <C558EB67-330F-48AE-A251-E244089311CB@gromit.dlib.vt.edu> In-Reply-To: <Y85nY7AgWMvhWruF@disp.intra.daemon.contact> References: <Y8oUemqHiPilKCK7@disp.intra.daemon.contact> <CAGudoHE4Sx_KY1vAsF1r8zXW6Y3vA4odRj6=bfm0fmLXFcVN9g@mail.gmail.com> <Y8qknwgR4quVXxay@disp.intra.daemon.contact> <CAGudoHH_ZP9%2BdZHb=6y10urYcYCwjdE1qOS2T6n4ennOSzVJ_A@mail.gmail.com> <Y85nY7AgWMvhWruF@disp.intra.daemon.contact>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C558EB67-330F-48AE-A251-E244089311CB>