Date: Fri, 24 Nov 2023 10:28:50 -0500 From: Chris Kiakas <chris@tellme3times.com> To: questions@freebsd.org Subject: Upgrade form 13.2-RELEASE-p5 to 14.0-RELEASE took almost 24hours Message-ID: <93C2E7DA-5E04-454B-9532-318292EEAE9A@tellme3times.com>
next in thread | raw e-mail | index | archive | help
--Apple-Mail=_E01E0B00-A1B2-440B-89E8-F273F42CD628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is the second system I=E2=80=99m upgrading which seems to take = forever compared to previous upgrades. The first system was a simple install that I use to test frr. The = system's original install was 13.2.-RELEASE and was upgraded over time = to 13.2-RELEASE-p5. 1TB ZFS HDD. The upgrade to 14.0-RELEASE was = standard up to the first reboot. After the reboot the next = freebsd-update install seemed to take a long time. I did=E2=80=99t pay = much attention because I was busy but there were no errors. It just felt = long. The second system has a raidz2 with 7 hard disks and is running 5 iocage = jails. It has 256G RAM. I=E2=80=99m in the process of the upgrade to = 14.0-RELEASE. Everything was as usual up until the second freebsd-upgrade install. The = one we preform after the reboot. It took about 20 hours. On the release notes we have the following; ZFS Changes OpenZFS has been upgraded to version 2.2. New features include: =E2=80=A2 block cloning, which allows shallow copies of blocks = in file copies. This is optional, and disabled by default; it can be = enabled with sysctl vfs.zfs.bclone_enabled=3D1. =E2=80=A2 scrub error log (zpool scrub -e) =E2=80=A2 BLAKE3 checksums, which are fast, and are now the = recommended secure checksums =E2=80=A2 corrective zfs receive can heal corrupted data =E2=80=A2 vdev and zpool user properties, similar to dataset = user properties. After searching on Google I came across; = https://www.reddit.com/r/freebsd/comments/181ayev/freebsd_14_stuck_during_= upgrade/ which discusses the following as a solution. Spurious fsync() in freebsd-update after every write interacts poorly = with the file system, mostly because block cloning is not enabled, so = copy_file_range turns into a massive pessimization. Suggested a workaround is: 'sysctl vfs.zfs.dmu_offset_next_sync=3D0' because you sure do not want to enable block cloning in ZFS. Problem was reported on freebsd-current in late October My question is; Is this the proper step to speed up the install or could this lead to = other issues? I have 5 iocage jails to upgrade and if they take as long as the = original upgrade It will take at least the whole weekend. Chris --Apple-Mail=_E01E0B00-A1B2-440B-89E8-F273F42CD628 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEi+l+WvjUMve3CBUQ0McJ9XNZ9LEFAmVgwTIACgkQ0McJ9XNZ 9LEQXRAAoRG7Y46oRMZpyT8vt2c4nnMzOifHOCEK1jt8XZCLZTEXzmX1qfil95rq gacZVQ96qGqggUtntutpEKGncOY4iNyID8pfKF36/X+XplZLxPmDGdXmII34ijjr epRadNaS4HNMKDvmLLRVSi8k3QSneIglX93+/vqVK0XiGqWe6TDZ4G4BZAdyspxc UklUUHfDxvpYkjkvDhFbbz/pBSB3osE8Xr+UR6gmDskDP2w5LaSGCZjbup6W1ig2 qaFucRD5oKPVMlcn48aJ5KppjmTxVsr8WgBlFPolaON2BYJHhhyM7byak2hkK8eq 0wi6rkLjvf89RxVHbiHNOcBG6lNuXo5nNV0lr3BBB7Ki/l/a3+HVOkpM6q/ootTt k6CgV9StIhvOq1RB9wxaavLtf2GvX4B0JLUuw45SIO1EaMVaPHSLsV/4gmWtKFsr 7DJq1hPxqahHYiKClR0CMag4fYZJT6vTmL+yaqhfiBiH45iEYnPNG8OMnDgPkCKs Cz1dKAIc3wrs9fEaYqN7uUS3Sf24vkbrTU7G8ywsPjTk+NRhFucqL3rKEx6S3r4Z OpqfRNhx3u5ftcCChJS0AHdZ7raLgw9mTkBfDoi0MYXWpDt3ZDD9DmmAxMZM84Fu j8BzryqNEuNxt8fbePVG7F7gGcPfXi32bIgAZD1VjkT3lWslIC4= =Ys3U -----END PGP SIGNATURE----- --Apple-Mail=_E01E0B00-A1B2-440B-89E8-F273F42CD628--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93C2E7DA-5E04-454B-9532-318292EEAE9A>