From nobody Tue Aug 15 12:05:47 2023 X-Original-To: current@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 4RQ93V5vhYz4Txtj for ; Tue, 15 Aug 2023 12:06:30 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RQ93V14Ffz3Rgd for ; Tue, 15 Aug 2023 12:06:30 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=eQGLZcVf; spf=pass (mx1.freebsd.org: domain of Alexander@Leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@Leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net Received: from webmail2.leidinger.net (roundcube.Leidinger.net [192.168.1.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: Alexander@Leidinger.net) by outgoing.leidinger.net (Postfix) with ESMTPSA id 6FECF312 for ; Tue, 15 Aug 2023 14:05:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1692101183; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DMlAqUx25Vn984TbSArXQR6fUwgSKJafbJTJOHgGLEE=; b=eQGLZcVfeo4pJSiLUb0m5IY2Xy2c2M59sU31mxAm6DZaFjHEPrw2GTvE+SKy2ojmfCDUyI ir+zSLcljmpr1n7mNeNODPkGdTLLKFJeUF7eTi/jLHDGMbzMMpkxRSaueZFZcb7DZJv9C1 gaW1Mz5oWOd0kdAaQa7N2faJ4zGVgIWXRNKVZ4VVDwGAkxpgV3GgWmxZ8XLTbdQJL8d/yW dr4hea6If89B1lvyT1R/8pLqKL0wl2Q5WczZuGVXAvUrVsFt0FIXIuFem9w9l9MvpJ22zo j/GC0RTcy3q+ubIBngYODDxwKztx0zcJ7gOMjdDITj3AM3tDSCZ4KXc/alc4Gg== List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Date: Tue, 15 Aug 2023 14:05:47 +0200 From: Alexander Leidinger To: current@freebsd.org Subject: Speed improvements in ZFS Message-ID: <61ca9df1b15c0e5477ff51196d0ec073@Leidinger.net> X-Sender: Alexander@Leidinger.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RQ93V14Ffz3Rgd Hi, just a report that I noticed a very high speed improvement in ZFS in -current. Since a looong time (at least since last year), for a jail-host of mine with about >20 jails on it which each runs periodic daily, the periodic daily runs of the jails take from about 3 am to 5pm or longer. I don't remember when this started, and I thought at that time that the problem may be data related. It's the long runs of "find" in one of the periodic daily jobs which takes that long, and the number of jails together with null-mounted basesystem inside the jail and a null-mounted package repository inside each jail the number of files and congruent access to the spining rust with first SSD and now NVME based cache may have reached some tipping point. I have all the periodic daily mails around, so theoretically I may be able to find when this started, but as can be seen in another mail to this mailinglist, the system which has all the periodic mails has some issues which have higher priority for me to track down... Since I updated to a src from 2023-07-20, this is not the case anymore. The data is the same (maybe even a bit more, as I have added 2 more jails since then and the periodic daily runs which run more or less in parallel, are not taking considerably longer). The speed increase with the July-build are in the area of 3-4 hours for 23 parallel periodic daily runs. So instead of finishing the periodic runs around 5pm, they finish already around 1pm/2pm. So whatever was done inside ZFS or VFS or nullfs between 2023-06-19 and 2023-07-20 has given a huge speed improvement. From my memory I would say there is still room for improvement, as I think it may be the case that the periodic daily runs ended in the morning instead of the afteroon, but my memory may be flaky in this regard... Great work to whoever was involved. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF