Date: Mon, 23 Jan 2023 11:54:27 +0100 From: Peter <pmc@citylink.dinoex.sub.org> To: Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: close() taking minutes (ZFS related) Message-ID: <Y85nY7AgWMvhWruF@disp.intra.daemon.contact> In-Reply-To: <CAGudoHH_ZP9%2BdZHb=6y10urYcYCwjdE1qOS2T6n4ennOSzVJ_A@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems I have found the reason for the strange behaviour: it is dedup. 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). I don't think it should lockdown the entire pool, but it is understandable that it creates a logical relation between the different filesets.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Y85nY7AgWMvhWruF>