From nobody Mon Aug 19 04:45:37 2024 X-Original-To: hackers@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 4WnKmF1hZZz5TxqD for ; Mon, 19 Aug 2024 04:45:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WnKmC3CVPz4vXb for ; Mon, 19 Aug 2024 04:45:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=SOZsCBBL; dkim=none ("invalid DKIM record") header.d=cse.huji.ac.il header.s=57791128 header.b=bjEL7rsk; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=KqZq8j8tVNSWuK0ZfJnArRo8HHdXp6Y4eBEkcAim8sM=; b=SOZsCBBLN1fpkiuZ7IhDsxDI7qRd+jMfFWMhWEDi17r6LVoctBntPgdYh4Gc3+B4bighbA7v3oW1z6ugI+8Ns+hq3/6SPSQtpD+Ri1D+LrUioVQBzcH6gqbjhY800n7+8Ks9AKql+g5UtgmffkRw67nSuFKslWL6B0GdtDFmiGxJexYtbbc9qUFmWAkdP0au4PKGoW4e6cdL2XEYhe9xkOBDTNjPOhzChB5ucMcCWIf1E3uddjgZUoiDnvZm9wDtofnT/XIbZf2zwcD96o6xUcgnsusLM5AjvdFWKiVsmhOfvIAkexyRcYGNj3ms9j0Gh3rTvM3cOTTlOkyerVzVqQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cse.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=KqZq8j8tVNSWuK0ZfJnArRo8HHdXp6Y4eBEkcAim8sM=; b=bjEL7rskb7ljkvnE8nImjwLPndwffYppkw4AodCzbGaaGfmYbqHiAqOP379fyQ9G7HrXRQDTMOu0fLzJXKDiHCLFTi++omQfaVD4sBxHeyCmzC8ir3srVUrCN05dHZOHA22b9LLNPkZq8a8nTYsgrnrGG23gqT7cXX3Gd4e8LFtMc71QoHYg3BbbLrowiMKY3fjQ0Iv+bIt37j1G0NtnWW2T31sYLyCO89E8tOQVGCndy06DlhZF00db8WrRQ1nLRYnPfbFvrl0dNA+CQKXD07v41yvLaxWAZPjCS7B1eQF+YQ+NCYjuoko+rwYGhPN1umzhXO8+qLu0iZVUefSskQ==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1sfuGv-000BwR-BM; Mon, 19 Aug 2024 07:45:37 +0300 From: Daniel Braniss Message-Id: <2A12A360-8C26-4D1C-ADD4-CB510BE35CA8@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_F9374A39-B997-49DD-AF3F-963D16C701F2" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: some issues with 14.1 Date: Mon, 19 Aug 2024 07:45:37 +0300 In-Reply-To: Cc: freebsd-hackers To: Warner Losh References: <50285854-3CB1-4F96-83B4-5A56233D8DA1@cs.huji.ac.il> X-Mailer: Apple Mail (2.3696.120.41.1.10) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.14 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.94)[-0.938]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_DKIM_PERMFAIL(0.00)[cse.huji.ac.il:s=57791128]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; DKIM_MIXED(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; DKIM_TRACE(0.00)[cs.huji.ac.il:+,cse.huji.ac.il:~] X-Rspamd-Queue-Id: 4WnKmC3CVPz4vXb --Apple-Mail=_F9374A39-B997-49DD-AF3F-963D16C701F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Aug 2024, at 20:46, Warner Losh wrote: >=20 >=20 >=20 > On Tue, Aug 13, 2024 at 1:28=E2=80=AFAM Daniel Braniss = > wrote: > hi, > these are some issues I=E2=80=99m having with 14.1. > 1- I use SOL to view the console via ipmi - not the serial but the = serial-over-lan. > up to13.2 all is ok, by all i mean: > 1 - boot/kernel/init output is visible > 2 - escape to debugger via \n~^B works. > 3 - /dev/console is fine > with 14.1: > 1- init output is missing (have to guess why multiuser fails = :-) > 2- no longer works > 3- is not working (hence explaining 1) > any insights? >=20 > This is likely due to using UEFI. How did you configure this before = with BIOS? it=E2=80=99s happening also with vmware and bhive so I don=E2=80=99t = think the BIOS is involved. managed to solve - magically- the kernel/init outputs, but now i=E2=80=99m still left with a non working escape to debugger, will have to check the changes in the kernel=E2=80=A6 thanks, danny >=20 > Warner=20 --Apple-Mail=_F9374A39-B997-49DD-AF3F-963D16C701F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 13 Aug 2024, at 20:46, Warner Losh <imp@bsdimp.com> = wrote:



On Tue, Aug 13, 2024 at 1:28=E2=80=AFAM = Daniel Braniss <danny@cs.huji.ac.il> wrote:
hi,
these are some issues I=E2=80=99m having with 14.1.
1- I use SOL to view the console via ipmi - not the serial but the = serial-over-lan.
    up to13.2 all is ok, by all i mean:
        1 - boot/kernel/init output is visible
        2 - escape to debugger via \n~^B works.
        3 - /dev/console is fine
   with 14.1:
        1- init output is missing (have to guess why = multiuser fails :-)
        2- no longer works
        3- is not working (hence explaining 1)
any insights?

This is likely due to using UEFI. How = did you configure this before with = BIOS?

it=E2=80= =99s happening also with vmware and bhive so I don=E2=80=99t think the = BIOS is involved.
managed to solve - magically- the = kernel/init outputs,
but now i=E2=80=99m still left with a non = working escape to debugger,
will have to check the changes in = the kernel=E2=80=A6
thanks,
= danny


Warner 

= --Apple-Mail=_F9374A39-B997-49DD-AF3F-963D16C701F2-- From nobody Mon Aug 19 17:21:44 2024 X-Original-To: freebsd-hackers@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 4WnfXT0vshz5T875; Mon, 19 Aug 2024 17:21:45 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WnfXT0bnYz4JZt; Mon, 19 Aug 2024 17:21:45 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724088105; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TeKsaMddvdd9scABpN5qtmpMyG3yaqYhasArGQr7+oo=; b=XlC0BHIgpl1TJJLtjdx5lFpOEeyoF5XJX7TiH/EjYAG4KhU1ud7i7i4kqBNBJUWRdb7+4n 1es5LowwrZwrCdHfgl3ibQb+LQcF6ud6bb8PXUpa9pUH0kylB2pYfgPL88yv+F94uqAL+h MoPx2XgbWV/U7LgER2wogoDdCqH/Pc5ZvQdg0IxdTytXVabBu7KKZXmErAL5HPjPSLiwmK J3uK05rxCd+F64S4aTqJ1ntslnXRnOXDprR+r0CeTPIMWsAB6KQK+FMcYxQdSNy7/Zxo9z 56Z9uePD7CSEUxzduzIBPLDmb7gP8RlbCGqIqNDHglnjfmNiyCbckXJb6QRvHA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1724088105; a=rsa-sha256; cv=none; b=leoOdLt/Or8tHf7jRRYOWEHlViNQTui3kOxMoPE1Ivx2UPggY8OTX0/L9tIRqCAF9+Ce9Q rDzQ6aZtSLKldn/rTF0ZkPNn1aOJfbAJFHiGpW6y3HGLdLbenxDMm9gpplobEiuWSVDmDa XLLftwFieQKcz5TS0L+stAvj/0VSEpvbqlpRGV9jiWlBt1UZ6+iU1bVmNNbUUcqlJ1Od93 HeuGipShfPC+9KNRbFK3mnMjb/sIkag9AaoAa9ujSHXEwYG6jG3x2mjkvYeHk46L83VETb etuFmG0xmbMaoUdOwnsfuOJ4EwzUGZ/7BV4uCE8S/w2+dt5IKwOyHayvKkWvSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1724088105; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TeKsaMddvdd9scABpN5qtmpMyG3yaqYhasArGQr7+oo=; b=Ajj27nfnbTIgBLLN9wiXdD3ObYnhmcEVt9BWMJbBtItQgzFbhQOleNqyLK1BS32PG5nptJ 5OV8Y9xXLP6nusOf6r72e7vgign9VqVx6VWa0drITl0T1GN4CtJQYMMPPYVGptM27WsJbh cfFWH57oMSoWDJbducgo/u9avxF6Ka6tGxN5i69Ez28EjxKrBLNavZ19Tpd0TUJET4sFza omNZoiKteGZVOE17y2DmaqQtweBko7TOyQhS3rbd3mCEHGYdn2lfo1Y0C4pcyeumoIrGyd vOVoJbSywqprCkNthVZCAS+vhClNBNzZV/CFWu8d3E/hBkQ6fmMIWMTqC1k5Jg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id E8C052EAB; Mon, 19 Aug 2024 17:21:44 +0000 (UTC) Date: Mon, 19 Aug 2024 17:21:44 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Status Report - Second Quarter 2024 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename="report.txt" Content-Transfer-Encoding: 8bit FreeBSD Status Report Second Quarter 2024 Here is the second 2024 status report, with 20 entries. It has been very difficult to publish this status report within the usual schedule: indeed we are late. Unfortunately many of us have been busy with a lot of stuff, both inside and outside FreeBSD, thus some reports arrived late and report publication was slower than usual. Hopefully, this quarter was an exception and next quarter we will already be back on track, with 2024Q3 report published within October 2024. Have a nice read. Lorenzo Salvadore, on behalf of the Status Team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2024-04-2024-06/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection • Projects □ Audio Stack Improvements □ FreeBSD GitHub Pull Request Report • Userland □ Capsicum-rs □ Service jails — Automatic jailing of rc.d services • Kernel □ Hierarchical rate limits for OpenZFS □ A low-cost conditional execution mechanism • Architectures □ FreeBSD/riscv64 • Cloud □ FreeBSD on Microsoft HyperV and Azure □ OpenStack on FreeBSD • Documentation □ Documentation Engineering Team • Ports □ GCC on FreeBSD □ KDE on FreeBSD □ FreeBSD Erlang Ecosystem Ports update • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. DevSummit 202405 The Core Team has presented the status update at the DevSummit 202405. Details are available at https://wiki.freebsd.org/DevSummit/202405 Passing of Mike Karels It is with a heavy heart that we have learned of Mike Karels' recent passing. We want to offer our sincere condolences to his family, friends, and the community for this loss. Mike was an inspirational fellow developer and will be sorely missed. In Memory of Mike Karels. For more details about him, please visit the FreeBSD Foundation’s page at: https://freebsdfoundation.org/mike_karels/ 2024 Core Team Election Core.12 appointed Muhammad Moinur Rahman (bofh@) and Allan Jude (allanjude@) as the managers of the 2024 Core Team election. After Allan decided to run for Core, Moin continued to handle all the election tasks independently. The result was announced on June 12th, with 8 members: • Allan Jude (allanjude@) • Dave Cottlehuber (dch@) • Gleb Smirnoff (glebius@) • Hiroki Sato (hrs@) • Li-Wen Hsu (lwhsu@) • Mathieu Arnold (mat@) • Olivier Cochard (olivier@) • Tobias C. Berner (tcberner@) Mike Karels has run for the 2024 Core Team election, and was in the top nine candidates in the result. After a discussion, core.13 came to the conclusion that the eight members will serve as the new team. Core.13 takes office on June 12th, and hold the handover meeting with core.12 on June 21st. The project thanks the outgoing core.12 members for their service in the last two years: • Baptiste Daroussin (bapt@) • Benedict Reuschling (bcr@) • Ed Maste (emaste@) • Greg Lehey (grog@) • John Baldwin (jhb@) • Emmanuel Vadot (manu@) • Mateusz Piotrowski (0mp@) Commit bits • Core approved the src commit bit for Osama Abboud (osamaabb@) • Core reactivated the src commit bit for Ryan Libby (rlibby@) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://freebsdfoundation.org/ Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/ Donate URL: https://freebsdfoundation.org/donate/ Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/ FreeBSD Journal URL: https://freebsdfoundation.org/journal/ Foundation Events URL: https://freebsdfoundation.org/our-work/events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the: • Software development projects to implement features and functionality in FreeBSD • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD • Purchase and support of hardware to improve and maintain FreeBSD infrastructure • Resources to improve security, quality assurance, and continuous integration efforts • Materials and staff needed to promote, educate, and advocate for FreeBSD • Collaboration between commercial vendors and FreeBSD developers • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity Last quarter we helped FreeBSD celebrate its 31st anniversary! This community sure loves to celebrate milestones like this one. We not only saw more users sharing their stories on social media, but many commercial users stepped in to promote their use cases and love for FreeBSD. It is exciting to see the growth of this project through the improvements made to FreeBSD, as well as the increase in users and contributors. Over the past few quarters, we have built up our technology, advocacy, and partnership teams to accelerate our work in improving the operating system, increasing the adoption and visibility of FreeBSD, and increasing the number of partners who help fund our work. Below you will find updates from each team to see the work we have accomplished to support you, the community and the operating system we all love. But, first I want to share a fundraising update. Last quarter we raised $41,154 towards our goal of raising over $2,000,000. You can see our 2024 budget to understand how we are spending your donations here: https://freebsdfoundation.org/wp-content/uploads/2024/03/Budget2024-Approved-Public.pdf. Over half the budget goes directly into improving and securing FreeBSD. If there is a security vulnerability out there, we have software developers on staff who can quickly step in, evaluate the situation, and put in a change or workaround if needed. We have a full-time developer who leads the continuous integration efforts and investigates ways to improve the tools to test code, improve test coverage, and help developers be more efficient. We have also allocated more funding towards our advocacy efforts. This includes creating content to highlight FreeBSD’s strengths and differentiators, talking to commercial users and documenting their use cases, and promoting the work you are doing. Please consider funding our efforts to help keep FreeBSD innovative, secure, and stable by making a donation here: https://freebsdfoundation.org/donate/. If you are a corporate user, please consider becoming a partner! Go here to find out more information about our partnership opportunities: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/. OS Improvements During the second quarter of 2024, 204 src, 50 ports, and 11 doc tree commits identified The FreeBSD Foundation as a sponsor. The Foundation is sponsoring 13 projects. • Christos Margiolis continued to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to facilitate sound development on FreeBSD. Refer to the Audio Stack Improvements entry for details. • Pawel Dawidek is in the final stages of a project to add hierarchical rate limits to OpenZFS. For details, refer to the Hierarchical rate limits for OpenZFS report entry and the pull request in the OpenZFS repository. • Long-term contractor Olivier Certner was active in a few different parts of the tree: □ rtprio(2): Updating the number of queues per runqueue from 64 to 256 □ UnionFS: reviewed work from Jason A. Harmening. Jason’s work fixes many locking problems (wild accesses without locks, deadlocks, etc.), particularly in unionfs_rename() and improves locking logic. □ Vnode recycling/ZFS ARC reclaim: Reviewed a fix for bug #275594, liaised with upstream to obtain and test a backport, had an EN issued and applied as 13.3-RELEASE-p2, and started longer-term work to improve the vnode reclaiming mechanisms and have ZFS pass the right information □ ULE scheduler: Updated to work on a single runqueue instead of 3 for POSIX compliance with respect to the number of distinct SCHED_FIFO/ SCHED_RR priority levels □ Miscellaneous: Many (26) reviews, ports updates, and investigated DRM problems □ Published a EuroBSDCon 2023 conference report in the FreeBSD Journal. • Pierre Pronchery continued work on a security-focused project with the Foundation that included: □ working on a conversion tool from VuXML to OSV □ automating the generation of VuXML reports across all ports with security/osv-scanner □ running Coverity Scan reports around bhyve and assisting in rectifying the reported defects • Work continued on a joint project between Advanced Micro Devices (AMD) and The FreeBSD Foundation to develop a complete FreeBSD AMD IOMMU driver. This work will allow FreeBSD to fully support greater than 256 cores with features such as CPU mapping and will also include bhyve integration. Konstantin Belousov has been working on various parts of the project, including driver attachment, register definitions, an ACPI table parser, and utility functions. Two key components that need to be completed are context handling, which is mostly a generalization of Intel DMAR code, and page table creation. After this, the AMD driver’s enable bit can be turned on for testing. To follow all of Konstantin’s work, look for src commits tagged with Sponsored by fields for Advanced Micro Devices (AMD) and The FreeBSD Foundation. • The Vector Packet Processor (VPP) is an open-source, high-performance user space networking stack that provides fast packet processing suitable for software-defined networking and network function virtualization applications. Tom Jones is wrapping up his part on a project to port VPP to FreeBSD. The code has been shared with RG Nets, a co-sponsor of the work, for extensive testing. • Björn Zeeb continued to improve wireless networking on FreeBSD. As with last quarter, the focus was mainly on bug fixes and stability improvements. Most of Bjoern’s 30+ src commits were to LinuxKPI and net80211 code. • Philip Paeps is working on a 20-hour-per-month, six-month contract to continue modernizing the FreeBSD cluster. This work includes moving more servers to our newest cluster site at NYI in Chicago. • Moin Rahman is under two contracts. Moin is nearing completion of a Center for Internet Security (CIS) hardening guide and continues work to establish pre-commit CI. • Mina Galić continues efforts to put FreeBSD cloud-init support on par with Linux support. • Mitchell Horne presented his RISC-V work at the FreeBSD developer summit. You can read about the latest developments in the FreeBSD/riscv64 report entry. • Refer to Chih-Hsin Chang's OpenStack on FreeBSD report entry for the latest updates on the project to port OpenStack components so that OpenStack can be run on FreeBSD hosts. Other members of the Foundation’s technology team contributed to FreeBSD development efforts. For example, Mark Johnston, along with Andrew Turner, authored basic routines to build a Flattened Device Tree (FDT) for arm64 bhyve guests. The FDT describes various hardware components like CPUs, memory, UART, PCIe controller, interrupt controller, and platform timer, which the guest OS needs to know about. Ed Maste committed a variety of src contributions, including modernization of tzsetup(8) and correcting an issue with diff(1) options. Balancing their regular responsibilities, Li-Wen Hsu and Joe Mingrone contributed updates and fixes to various ports, including addressing pressing security issues. FreeBSD is participating in the 20th consecutive Google Summer of Code. The 11 projects for this summer are well underway. Continuous Integration and Workflow Improvement As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and test infrastructure. Partnerships and Research In the Second Quarter, Greg Wallace, the Foundation Partnerships lead, attended the Open Source Summit event in Seattle. There he joined Doug Rabson who gave a talk on the work of the FreeBSD OCI Runtime Extension working Group. You can check it out here. Greg also used the event to connect with a number of key tech companies to advance major joint technology initiatives. Greg’s write up on the event is here. Work continues on other highly-requested features. RG Nets and others have been making great strides to bring CUDA and related AI stack components to FreeBSD. The Foundation is seeking ways to coordinate across users of FreeBSD to get support for a variety of AI technologies on FreeBSD. One idea is to launch a FreeBSD AI lab that would pool money from supporters to get CUDA fully supported on FreeBSD and to round out DPU driver support. Please contact us if you would like to support such an initiative. Work continues to leverage the heroic work from the FreeBSD Community to get .NET supported on FreeBSD so that downstream dependencies can in turn better support FreeBSD. More to come on this front soon. Thanks to the generous grant from Alpha-Omega, the FreeBSD Foundation has undertaken two code audits of important subsystems carried out by Synactiv. Alpha-Omega is an open source project with a mission to protect society by catalyzing sustainable security improvements to the most critical open source software projects and ecosystems. Our most recent monthly update can be found here. The code audits will conclude in July and then we will then undertake a process audit and will also run a 2FA pilot. In Q1 and Q2, Greg participated in several meetings about various government regulations. In March, he represented FreeBSD at the CISA two-day Open Source Software (OSS) Security Summit alongside other Open Policy Alliance members. Previously, Greg collaborated with OPA to submit comments to CISA’s RFC on how the US Government can support the security and sustainability of Open Source. And in June, The FreeBSD Foundation joined the Open Regulatory Compliance Working Group at the Eclipse Foundation. This group aims to accelerate the development of cohesive cybersecurity processes required for regulatory compliance while offering a neutral environment for hosting technical discussions with the open source community at large. We are thrilled to welcome Alice Sowerby as a part time, contract Partnerships Program Manager. Alice is an experienced, multi-skilled leader, currently active in a number of open source domains. She is the co-host of the CHAOSS podcast and chair of the TODO group review team for the OSPO Book. Alice is providing program and project management for partnership initiatives, like Alpha-Omega, OCI FreeBSD Runtime Extension WG, and the Enterprise Working Group. Advocacy During the second quarter of 2024, we continued growing our efforts to drive awareness, advocate for the project, highlight users, and bring educational content to the FreeBSD community. Below are some of those efforts. • Organized the May 2024 FreeBSD Developer Summit, co-located with BSDCan. Check out both the videos and write ups from Summit. • Celebrated FreeBSD’s 31st Birthday with FreeBSD Week, which included many new user stories, and an interview with Beastie! • Released the Final Report from the 2024 FreeBSD Community Survey. • Announced the winners of the first annual Digital Security by Design (DSbD) Ecosystem Beacon Awards to celebrate innovators working with and enhancing CheriBSD. The Beacon awards are sponsored by the Foundation in partnership with Innovate UK and Digital Security by Design (DSbD). • Provided an overview of FreeBSD 14.1. • Updated the FreeBSD End User page with new interviews and a number of new case studies including ones from Netflix, Metify, and RGNets. • Published numerous blogs including: □ FreeBSD Foundation Delivers V1 of FreeBSD SSDF Attestation to Support Cybersecurity Compliance □ FreeBSD: The torchbearer of the original operating system distribution □ The 2024 FreeBSD Foundation Budget Journey: Choosing Where We Invest □ Why FreeBSD Continues to Innovate and Thrive □ Innovating the Future: Arm’s Strategic Embrace of FreeBSD □ Why FreeBSD Events are Important to Furthering the Development of FreeBSD • Participated in the following contributed articles, interviews and podcasts: □ CIO Influence interview with Deb Goodkin □ SustainOSS Podcast interview with Deb Goodkin Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://freebsdfoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 14.1-RELEASE announcement URL: https://www.freebsd.org/releases/14.1R/announce/ FreeBSD 13.4-RELEASE schedule URL: https://www.freebsd.org/releases/13.4R/schedule/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The Team mourns the loss of Mike Karels, who was the Deputy Release Engineering Lead and mere days before his death agreed to take the role of Release Engineer for 13.4-RELEASE. The Team managed 14.1-RELEASE, leading to the final RELEASE build and announcement in June. During the second quarter of the year, the Team has gained new members: Ed Maste (Deputy Release Engineer Lead), Dave Cottlehuber, John Hixson, Mahdi Mokhtari, Doug Rabson, Muhammad Moinur Rahman. Planning has started for the upcoming 13.4-RELEASE cycle. The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/14, and stable/13 branches. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications. In this quarter, the team has worked on the following: • Regular support for FreeBSD.org user accounts. • Regular disk and parts support (and replacement) for all physical hosts and mirrors. • Cluster software refresh. • Moving cluster services to Chicago. Cluster software refresh Except for the package builders and developer-facing ("dogfood") machines, the FreeBSD cluster mostly tracks stable/X branches. This quarter, we started moving the stable/13 hosts to stable/14. At the time of this writing, there are 133 physical machines in the cluster, 48 run current, and 64 have been upgraded to stable/14. The remaining machines are slated for upgrading or decommissioning in the near future. Of the 290 jails in the cluster, 206 run stable/14. 12.x: Regular 2, Jails 8 13.x: Regular 19, Jails 68 14.x: Regular 64, Jails 206 >15.x: Regular 48, Jails 8 ----------------------------- Total: Regular 133, Jails 290 Total installations: 423 Running -RELEASE|{-p*}: 0 Total geographic sites: 16 Moving cluster services to Chicago Earlier this year, we started building up our new site in Chicago. This quarter, we began decommissioning older machines in New Jersey and moving services to the newer machines in Chicago. Our long-term goal is for Chicago to become our primary location. This work will take several more months to complete. FreeBSD Official Mirrors Overview Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror site), United States of America — California, Chicago, New Jersey (primary site), and Washington. The hardware and network connection have been generously provided by: • Cloud and SDN Laboratory at BroadBand Tower, Inc • Department of Computer Science, National Yang Ming Chiao Tung University • Equinix • Internet Association of Australia • Internet Systems Consortium • INX-ZA • KDDI Web Communications Inc • Malaysian Research & Education Network • MetaPeer • New York Internet • NIC.br • Teleservice Skåne AB • Your.Org New official mirrors are always welcome. We have noted the benefits of hosting single mirrors at Internet Exchange Points globally, as evidenced by our existing mirrors in Australia, Brazil, and South Africa. If you are affiliated with or know of any organizations willing to sponsor a single mirror server, please contact us. We are particularly interested in locations on the United States West Coast and throughout Europe. See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site. Sponsors: The FreeBSD Foundation and Netzkommune ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI Tinderbox view URL: https://https://tinderbox.freebsd.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI 3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet In the second quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD. Important completed tasks: • Added new hardware purchased by the FreeBSD Foundation in Chicago site to the CI cluster • Repurposed decommissioned pkg builder as build agent and added to the CI cluster • Adjusted the job dispatching mechanism based on the machine capability • bofh@ merged https://reviews.freebsd.org/D43786 as Add preliminary in-tree CI infrastructure for developers so they can replicate an environment or results similar to https://ci.FreeBSD.org • Decommission armv6 jobs for the main branch Work in progress tasks: • Merging Pre-commit CI with CIRRUS-CI • Designing and implementing pre-commit CI building and testing and pull/ merge-request based system (to support the workflow working group) • Proof of concept system is in progress. • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Redesigning the hardware test lab and adding more hardware for testing Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://ports.FreeBSD.org Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: Tobias C. Berner Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. According to INDEX, there are currently 32,471 ports in the Ports Collection. There are currently ~3,497 open ports PRs. The last quarter saw 10,525 commits by 160 committers on the main branch and 1771 commits by 107 committers on the 2024Q2 branch. Compared to last quarter, this means a large decrease in the number of commits on the main branch (down from 12,991) and backports to the quarterly branch (compared to 888). The number of ports also increased (up from 32,244). The most active committers to main were: • sunpoet 3739 • yuri 1450 • jbeich 491 • eduardo 220 • bofh 200 • diizzy 197 • rene 188 • fernape 156 • jhale 133 • arrowd 129 A lot has happened in the ports tree in the last three quarter, an excerpt of the major software upgrades is: • pkg 1.21.3 • Default version of lazarus switched to 3.4.0 • Default version of fpc switched to 3.2.3 • Default version of python switched to 3.11 • chromium updated from 123.0.6312.86 to 126.0.6478.126 • firefox updated from 124.0.1 to 127.0.2 • firefox-esr updated from 115.9.0 to 115.12.1 • rust updated from 1.77.0 to 1.79.0 • sdl2 updated from 2.6.3 to 2.8.2 • wlroots updated from 0.17.2 to 0.17.4 • wine updated from 8.0.2 to 9.0 • wine-devel updated from 9.4 to 9.11 • xorg-server updated from 21.1.11 to 21.1.13 • qt5 updated from 5.15.13 to 5.15.14 • qt6 updated from 6.6.3 to 6.7.2 • kf5 updated from 5.115.0 to 5.116.0 • kf6 updated from 6.0.0 to 6.3.0 • plasma6 updated from 6.0.2 to 6.1.1 During the last quarter, pkgmgr@ ran 24 exp-runs to test various ports upgrades, updates to default versions of ports, subpackage support and base system changes. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Audio Stack Improvements Contact: Christos Margiolis The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature. Important work since last report: • Asynchronous audio device detach is now possible. This functionality already ships with FreeBSD 14.1-RELEASE, as well as 14-STABLE. • Got rid of the "snd_clone" device cloning framework used in sound(4) and replaced it with DEVFS_CDEVPRIV(9). More info about behavior changes in the commit description. Also ships with 14.1-RELEASE and 14-STABLE. • Several sound(4) crash and bug fixes. • More out of the box support for snd_hda(4) laptop sound. • Series of commits that clean up and simplify parts of sound(4). • Several fixes regarding the OSS API, with the most notable so far being a proper implementation of the SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO IOCTLs. • Started implementing audio(3), an OSS audio and MIDI library. • Took over maintenance of virtual_oss(8). Future work includes: • Implementation of an audio(8) utility, in similar fashion to mixer(8). • Implementation of a bluetooth device management utility. • Improve mixer(3) and mixer(8). • Improve documentation and test suite where needed. • Attempt to find a better (ideally automatic) way to handle snd_hda(4) pin-patching. This is an experimental attempt and is not guaranteed to actually yield a working result. You can also follow the development process in freebsd-multimedia@, where I post regular reports. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD GitHub Pull Request Report Links: GitHub Working Group wiki page URL: https://wiki.freebsd.org/WorkingGroup/GitHub FreeBSD Base System Pull Requests URL: https://github.com/freebsd/freebsd-src/pulls Contact: Warner Losh The FreeBSD Project has been trying an experiment to accept contributions via GitHub pull requests. We have learned a lot in the last year that we’ve been doing this. We have created a number of rules relating to the pull requests. In general, pull requests should only be for things that are user-visible, add value to the project and are ready to go, modulo final review. Current status: • We are able to keep up with the pull requests doing everything by hand, but only if we do it at least weekly. • We have discovered the by-hand process is tedious and error-prone. • We can stage multiple pull requests in a testing branch so we can batch-up testing. • We can automatically land the result so merged pull requests show up as merged in GitHub infrastructure. We need help with automating the process: • Add automated testing that is context specific (for example, run igor over man pages). • Add build/install tests that test-boot the resulting image. • Automate common tasks, like man page corrections, into staging process. • Add simple smoke testing for the staging branch for tier 1 architectures. • Investigate optionally integrating Jenkins testing to scale up the size of changes we can accept. • Integrate with Bugzilla problem reports and Phabricator reviews. • Improve the submitter experience on GitHub by automating common feedback to mistakes in the pull requests. • Create checklists for submitters to reduce errors. • Create better reporting about pull requests, especially the frequent contributors of good pull requests. We are coordinating on FreeBSD’s Discord in the #github-hacking channel. Join us there to pitch in, or just chat about the project. Once things are fine-tuned, we want to publicity to steer contributors, at least the base system, to GitHub pull requests. We need more developers looking at the FreeBSD GitHub pull requests. We will also need more developers to review and land pull requests once it is automated and the automation has matured. We sincerely hope that we can improve the FreeBSD contribution experience with this, as well as gain useful fixes from the community. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Capsicum-rs Links: capsicum-rs on GitHub URL: https://github.com/dlrobertson/capsicum-rs capsicum-net on GitHub URL: https://github.com/asomers/capsicum-net Contact: Alan Somers Capsicum is a lightweight OS capability and sandbox framework implementing a hybrid capability system model. I have adopted the library providing Rust bindings for Capsicum, and extended it with support for libcasper(3) and cap_net(3). It is already being used by net-mgmt/nfs-exporter and by a TLS-enabled FTP server (the FTP server is closed-source, but all of the interesting bits reside in an open source library, and an example server can be found at https://github.com/bolcom/libunftp/tree/master/crates/unftp-sbe-fs/examples). Sponsor: Axcient ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Service jails — Automatic jailing of rc.d services Links: rc-article part for Service Jails URL: https://docs.freebsd.org/en/articles/rc-scripting/#rcng-service-jails Contact: Alexander Leidinger Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)). The base system infrastructure and the basesystem rc.d services are committed to 15-current, and the handbook / rc article updates are committed to the documentation. Next steps are to extend services in the ports collection to be able to make use of it. If you want to put e.g. nginx into a service jail and allow IPv4 and IPv6 access, simply change rc.conf(5) to have: nginx_svcj_options=net_basic nginx_svcj=YES While this does not have the same security benefits as a manual jail setup with a separate filesystem and IP/VNET, it is much easier to set up, while providing some of the security benefits of a jail like hiding other processes of the same user. Any testing and feedback (even as simple as "service X works in a service jail") is welcome. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. Hierarchical rate limits for OpenZFS Links: Pull request URL: https://github.com/openzfs/zfs/pull/16205 Contact: Pawel Dawidek Rate limits allow to limit bandwidth and number of metadata operations per dataset. Hierarchical rate limits allow for granular resource control especially in shared environments, eg. when a single ZFS pool serves data to multiple, independent virtual machines or jails. Because the limits are hierarchical, they are enforced like the quota property: the children datasets must obey the limits of the parent dataset. The limits can be configured using six new properties: limit_bw_read, limit_bw_write, limit_bw_total, limit_op_read, limit_op_write, limit_op_total The limit_bw_* properties limit the read, write, or combined bandwidth, respectively, that a dataset and its descendants can consume. Those limits are in bytes per second. The limit_op_* properties limit the read, write, or both metadata operations, respectively, that a dataset and its descendants can generate. Those limits are in number of operations per second. Limits are applied to file systems and ZFS volumes (and their snapshots). The initial work is done and the pull request is up for review. Sponsor: Klara Systems Sponsor: FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A low-cost conditional execution mechanism Links: FreeBSD wiki URL: https://wiki.freebsd.org/SummerOfCode2024Projects/ZeroCostConditionalExecutionMechanism Contact: Marko Vlaić Contact: Bojan Novković (mentor) < bnovkov@freebsd.org> This project aims to implement a low-cost conditional execution mechanism, similar to the static_key interface in Linux. The current working name is zcond, as in zero-cost conditional. The idea is to reduce the overhead of rarely used features in performance sensitive kernel code paths. Specifically, code blocks of the following, simple structure, are targeted: if(some_global_flag == true) { do_some_additional_task(); } A block like this can cause performance overhead in a frequently executed piece of code. The motivating use case for the mechanism is tracing (as outlined here in the wiki), but the project will identify more areas where this mechanism could be applied. The backbone of the mechanism is runtime instruction hot patching, making it highly architecture dependent. Great care has to be given to security, because kernel instructions are overwritten at runtime. More details and some implementation ideas can be found in the project proposal on the project wiki page. More documents describing the implementation and design decisions will be produced, as the project moves along. The goal of the project is to produce a working implementation of the mechanism for the x86-64 architecture. It will then be applied to an existing piece of kernel code and benchmarked. If the benchmark results come out positive, it will be ported to other architectures. This project is a part of the Google Summer of Code 2024.. The project is still in its early stages, but any feedback would be highly appreciated. Help wanted • General feedback on the mechanism, API and implementation • More use cases besides tracing are welcome • Code review • Name suggestions Sponsor: Google LLC (GSoC 2024) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for new hardware platforms. FreeBSD/riscv64 Links: Wiki Homepage URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: Ruslan Bukin Contact: Jari Sihvola The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. BSDCan Devsummit Updates Mitchell gave a presentation on the status of the FreeBSD/riscv64 platform at the June developers' summit, part of BSDCan 2024. The presentation discussed the challenges of supporting the evolving RISC-V ISA, and gave a brief overview of some available hardware targets. It is informal in nature, but available to watch on youtube. https://www.youtube.com/watch?v=O7zW7Z9U0ns StarFive JH7110 SoC / VisionFive v2 Work has been ongoing to support the JH7110 RISC-V SoC in FreeBSD. This SoC is present in several existing RISC-V SBCs. The primary support target is the VisionFive v2, but this work is likely to benefit similar hardware such as the Pine64 Star64 and the Milk-V Mars. At present, the support in CURRENT is partially complete. What is working: * UART * clk/reset drivers * MMC/SD The next target is working ethernet, which is supported with extensions to the if_eqos driver. This code is functional, but still in review. Work on this has been performed by Jari, with review, testing, and integration from Mitchell. https://wiki.freebsd.org/riscv/StarFive T-HEAD/XuanTie CPU Support As discussed in the devsummit presentation, these CPUs present several barriers to support. The problems come primarily from custom vendor extensions: non-coherent device I/O with custom cache management instructions, and a custom (spec-violating) implementation of page-based memory types. Combined, these quirks require difficult and invasive changes to pmap, busdma, and early boot code. At the same time, we are seeing an increasing amount of available hardware based on this IP, and so support becomes a repeated question and incentive. Work on page-based memory types is underway and expected to land soon in CURRENT. This feature allows individual virtual memory pages to be assigned specific properties, e.g. cacheability requirements. The riscv64 pmap has been extended to support the official RISC-V 'Svpbmt' extension, and the T-HEAD version of PBMT. These alternative encodings are incompatible, but provide similar functionality. Work on the device coherence and cache management challenges will begin next quarter. The hope is that this foundational work will (eventually) enable board support for available RISC-V hardware such as: * Allwinner D1 (Nehza) * Sipeed Lichee Pi 4A * Beagle-V Ahead * Milk-V Pioneer RISC-V Hypervisor Experimental support for the RISC-V hypervisor in bhyve/vmm(4) is under active development. Currently, single-core VMs are possible, and the guest can boot to multi-user. Note: the "H" (hypervisor) extension is not implemented by any known existing or upcoming RISC-V hardware. It is fully supported by software simulators such as Spike or QEMU. https://wiki.freebsd.org/riscv/bhyve Sponsor: The FreeBSD Foundation (mhorne’s work) Sponsor: UKRI (br’s work) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cloud Updating cloud-specific features and bringing in support for new cloud platforms. FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Souradeep Chakrabarti Contact: Li-Wen Hsu In this quarter, we have published the 14.1-RELEASE on Azure Marketplace. Souradeep Chakrabarti from Microsoft has improved the TLB flushing mechanism in Azure. Work in progress tasks: • Automating the image building and publishing process and merging to src/ release/. • Building and publishing snapshot builds to Azure community gallery. • Testing adding FreeBSD support in Azure Pipelines □ https://github.com/microsoft/azure-pipelines-agent/pull/3266 The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft. Open tasks: • Update FreeBSD-related doc at Microsoft Learn • Update sysutils/azure-agent to the latest version • Upstream local modifications of Azure agent • Port Linux Virtual Machine Extensions for Azure Sponsor: Microsoft for people in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org/ OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu The OpenStack on FreeBSD project aims to integrate OpenStack cloud infrastructure with the FreeBSD operating system, utilizing FreeBSD’s unique features while maintaining compatibility with OpenStack standards. In the second quarter of 2024, we continued to advance the project significantly. One of our key activities was attending BSDCan 2024, where we presented on "Towards a Robust FreeBSD-based Cloud: Porting OpenStack Components". This presentation helped increase the project’s visibility and attracted interest from potential contributors. We expanded the current single-node proof-of-concept (POC) site to a three-node setup. This involved detailed environment setup and network planning. Additionally, we began migrating the base to FreeBSD 15.0-CURRENT to ensure our project stays aligned with the latest advancements in FreeBSD. We also started working on adapting the manual installation steps and code patches into FreeBSD ports, aiming to streamline the installation process for future users. Another major milestone was initiating work on making bare-metal provisioning function on both FreeBSD instances and service hosts for OpenStack Ironic. Looking forward to the next quarter, our focus will be on refining these advancements and further enhancing the project’s robustness and ease of use. Specifically, we aim to upgrade our OpenStack components from the Xena version to a more recent release, as Xena has entered the "unmaintained" phase and will soon reach EOL. We welcome any suggestions and contributions from the community to help us achieve our goals. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/url Link: FreeBSD Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/url Link: Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-docengurl Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. Document changes During this quarter multiple pieces of the documentation were updated including the removal of mentions to ports that were removed from the ports tree, typos, URL corrections, and asciidoc improvements. These are three highlighted contributions in this quarter: • Best practices related to vendor import were documented. URL: https://cgit.freebsd.org/doc/commit/?id=fe494e72df138266f6da2b9170cf0215275a6aaf • A section about service jails was added to the handbook. URL: https://cgit.freebsd.org/doc/commit/?id=8f4754a9a6ee8f2503cfb68d14afa99b17729e7f • bhyve documentation was improved. URL: https://cgit.freebsd.org/doc/commit/?id=68cbd16c4e7c199cfdfb2b54110ad1470b4d7a2e FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblateurl Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/url Q2 2024 Status • 17 team languages • 214 registered users 9 new translators joined Weblate: • BFR (de_DE) • Elwood (de_DE) • Freebsd-Freund (de_DE) • MSantos (pt) • SINF-KEN (fr_FR, nl_NL) • aperechnev (ru) • edsonwolf • fdecunta (es_ES) • wheatfox (zh_CN, zh_HANS) Languages • Chinese (Simplified) (zh-cn) (progress: 7%) • Chinese (Traditional) (zh-tw) (progress: 3%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Greek (el) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 5%) • Korean (ko) (progress: 32%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Polish (progress: 2%) • Portuguese (progress: 0%) • Portuguese (pt-br) (progress: 22%) • Spanish (es) (progress: 36%) • Turkish (tr) (progress: 2%) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. Packages maintained by DocEng During this quarter the following work was done in packages maintained by doceng@: • textproc/docproj-legacy: Fix build with DBLATEX • textproc/docproj-legacy: Fix poudriere warning • textproc/rubygem-asciidoctor-epub3: Add missing run dependency • www/gohugo: Update to 0.125.4 Open issues There are 3 Open PRs in bugzilla assigned to doceng@: • 279815 status reports: ERR_TOO_MANY_REDIRECTS • 276923 www/gohugo link error under poudriere • 267274 Please remove the zh-CN Handbook of the current FreeBSD website During this quarter doceng@ closed 3 PRs: • 278904 misc/freebsd-doc-en: HTML should be single page • 278732 www/gohugo: Update to v125.5 • 278504 textproc/rubygem-asciidoctor-epub3: A run-time dependency is missing for rubygem-asciidoctor-epub3 port ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. GCC on FreeBSD Links: GCC Project URL: https://gcc.gnu.org/ GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ GCC 13 release series URL: https://gcc.gnu.org/gcc-13/ GCC 14 release series URL: https://gcc.gnu.org/gcc-14/ Contact: Lorenzo Salvadore Upstream has released GCC 14.1. Therefore port lang/gcc-14 has been created, as well as lang/gcc15-devel which tracks the new latest development GCC version. Previous major versions of GCC are being updated as well. Only very little work has been done on existing bugs for GCC ports this quarter, contrary to the original plan stated in the precedent report. This is due to the fact that I noticed an increasing interest in upstream to support GCC on FreeBSD, which however gets blocked by the fact that GCC sources do not build out-of-the-box on our platform, but needs instead many patches which are in our ports tree framework. It is then necessary to focus on upstreaming all of those patches, possibly at once and not one at the time as it has been done until now, and to also regularly run the tests suite, fixing all tests that fail. Then I am working on a new setup of automation that allows me to build and test all supported GCC versions as efficiently as possible, including GCC from sources but without the ports tree framework support. All of this has significantly slowed down usual GCC ports maintainership (users of the -devel ports have probably noticed that they are being updated much less frequently), but I am confident that it will eventually pay off. It should also be noted that Robert Clausecker has enabled lang/gcc11, lang/ gcc12, and lang/gcc13 for riscv64 architecture as the ports build fine on 15-CURRENT. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE/FreeBSD initiative URL: https://freebsd.kde.org/ FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation. We missed a quarter, while the broader KDE community celebrated the KDE Megarelease of KDE Frameworks 6, KDE Plasma 6 and KDE Gear. The latest software is still not available on FreeBSD, pending more testing and some integration work. Infrastructure CMake was updated several times and is now version 3.29.6, the latest upstream release. CMake in the ports framework now supports setting parallel-build for tests. Qt5 is now on long-term support and updates only rarely. An update to 5.15.14 and WebEngine to 5.15.17 was landed in May. Qt6 and the Python bindings for Qt, Pyside, were updated to version 6.7.2. KDE Stack KDE Gear, Plasma and Frameworks release happen very regularly. These updates arrive in the FreeBSD ports tree only piecemeal, due to lagging work on compatibility and testing. • KDE Frameworks reached version 6.3.0 • KDE Plasma 6 Desktop was updated to version 6.0.4 • KDE Gear 6 has not yet arrived in the ports tree Related Ports The KDE ecosystem includes a wide range of ports — most maintained by kde@, all building on a shared base of Qt and KDE Frameworks. The KDE team updates them all as needed. This quarter the KDE team would like to thank Tobias C. Berner, Gleb Popov and Jason E. Hale again for keeping things up-to-date. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Erlang Ecosystem Ports update Links: FreeBSD Erlang wiki URL: https://wiki.freebsd.org/Erlang Erlang/OTP language URL: https://erlang.org/ Elixir language URL: https://elixir-lang.org/ Gleam language URL: https://gleam.run/ Contact: FreeBSD Erlang mailing list The Erlang runtime system, commonly known as the BEAM, provides a runtime that is used by a number of programming languages and applications in the FreeBSD ports collection. Notable changes in 2024 include: • adding OTP27, the latest Erlang runtime release, Elixir 1.17, and Gleam 1.20 • more than 57 point release updates so far in 2024 • improved inline documentation within Erlang ports • moved RabbitMQ port to the generic UNIX build, decoupling this from Elixir as a build-time dependency. This enables moving RabbitMQ to the latest supported release. Users of RabbitMQ need to update each quarter to avoid being stuck on an unsupported release of Erlang/OTP + RabbitMQ Note that as the upstream Erlang OTP team only commit to supporting the two latest major releases, more and more point updates are arriving for OTP26-27, but not for the older Erlang runtime releases, which are now unlikely to get security and bug fixes. During 2024Q3, the Erlang team is planning to: • migrate the base lang/erlang port to OTP26 and update related dependencies Additional testing and community contributions are welcome, please reach out on the mailing list, especially if you are able to help testing of specific port updates. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on GitHub URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Bretton Vine (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad. During this quarter, there were no new Pot releases. Potluck images saw some updates again though. All images have been rebuilt for the new quarterly packages, a new Opensearch container has been added. Additional features, updates and fixes have been committed to containers like PostgreSQL-Patroni or Nomad-Server-TLS. In total, there are 58 container images and templates available now. As always, feedback and patches are welcome. Sponsors: Nikulipe UAB, Honeyguide Group From nobody Mon Aug 19 18:23:14 2024 X-Original-To: freebsd-hackers@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 4Wngvd3jRRz5TFjB; Mon, 19 Aug 2024 18:23:25 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mail.nepustil.net (mail.nepustil.net [IPv6:2001:14f8:1:1::8]) (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 4Wngvc0bjYz4WGL; Mon, 19 Aug 2024 18:23:23 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE designates 2001:14f8:1:1::8 as permitted sender) smtp.mailfrom=Axel.Rau@Chaos1.DE Received: from [2001:14f8:21c:10::124] (port=51544 helo=axels-imac.in.chaos1.de) by mail.nepustil.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98 (FreeBSD)) (envelope-from ) id 1sg71r-00000000Jsb-3WAv; Mon, 19 Aug 2024 20:23:12 +0200 From: Axel Rau Content-Type: multipart/mixed; boundary="Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: USBasp no longer works with FreeBSD 14.1 / avrdude 7.3 Message-Id: <30B9438F-FC5F-43CA-9A81-5E75F01017F0@Chaos1.DE> Date: Mon, 19 Aug 2024 20:23:14 +0200 To: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.77 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:+,4:~,5:+,6:~,7:+]; RCVD_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-hardware@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[chaos1.de]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4Wngvc0bjYz4WGL --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, Once a year, I flash some ATtinys. For ATtin861, i use USBasp from https://www.fischl.de/usbasp/ . USBasp worked fine with FreeBSD 13.2 / avrdude 7.0 [1] Now after upgrading the OS and avrdude, it fails: - - - usbd_set_config_index: could not read device status: USB_ERR_STALLED ugen0.2: at usbus0 umodem0 on uhub0 umodem0: on usbus0 umodem0: data interface 1, has no CM over data, has break ugen0.2: at usbus0 (disconnected) umodem0: at uhub0, port 5, addr 22 (disconnected) umodem0: detached - - - [2][3]. Any tips welcome, Axel PS: [1] --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Disposition: attachment; filename=t861.log Content-Type: application/octet-stream; x-unix-mode=0644; name="t861.log" Content-Transfer-Encoding: 7bit [root@home2l-admin ~/admin]# sh flash_t861.sh avrdude: Version 7.1 Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS System wide configuration file is /usr/local/etc/avrdude.conf User configuration file is /root/.avrduderc User configuration file does not exist or is not a regular file, skipping Using Port : /dev/cuau0 Using Programmer : usbasp Setting bit clk period : 10.0 AVR Part : ATtiny861 Chip Erase delay : 4000 us PAGEL : PB3 BS2 : PB2 RESET disposition : dedicated RETRY pulse : SCK Serial program mode : yes Parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 4 0 no 512 4 128 4000 4000 0xff 0xff flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00 calibration 0 0 0 0 no 1 1 0 0 0 0x00 0x00 Programmer Type : usbasp Description : USBasp, http://www.fischl.de/usbasp/ avrdude: set SCK frequency to 93750 Hz avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e930d (probably t861) avrdude> -c usbasp -p t861 -P /dev/cuau0 -t -B 100kHz -v avrdude do_cmd() error: (cmd) command -c is invalid avrdude> -c usbasp -p t861 -P /dev/cuau0 -t -B 100kHz -v [root@home2l-admin ~/admin]# avrdude -c usbasp -p t861 -P /dev/cuau0 -t -B 100kHz -v avrdude: Version 7.1 Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS System wide configuration file is /usr/local/etc/avrdude.conf User configuration file is /root/.avrduderc User configuration file does not exist or is not a regular file, skipping Using Port : /dev/cuau0 Using Programmer : usbasp Setting bit clk period : 10.0 AVR Part : ATtiny861 Chip Erase delay : 4000 us PAGEL : PB3 BS2 : PB2 RESET disposition : dedicated RETRY pulse : SCK Serial program mode : yes Parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 4 0 no 512 4 128 4000 4000 0xff 0xff flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00 calibration 0 0 0 0 no 1 1 0 0 0 0x00 0x00 Programmer Type : usbasp Description : USBasp, http://www.fischl.de/usbasp/ avrdude: set SCK frequency to 93750 Hz avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e930d (probably t861) avrdude> avrdude done. Thank you. [root@home2l-admin ~/admin]# sh avrdude.sh usbasp t861 cuau0 100 avrdude -c usbasp -p t861 -P /dev/cuau0 -B 100kHz -v -U hfuse:w:/usr/local/home2l/share/brownies/init.t861.elf -U efuse:w:/usr/local/home2l/share/brownies/init.t861.elf -U eeprom:w:/usr/local/home2l/share/brownies/init.t861.elf -U flash:w:/usr/local/home2l/share/brownies/init.t861.elf avrdude: Version 7.1 Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS System wide configuration file is /usr/local/etc/avrdude.conf User configuration file is /root/.avrduderc User configuration file does not exist or is not a regular file, skipping Using Port : /dev/cuau0 Using Programmer : usbasp Setting bit clk period : 10.0 avrdude: input file /usr/local/home2l/share/brownies/init.t861.elf auto detected as ELF avrdude: input file /usr/local/home2l/share/brownies/init.t861.elf auto detected as ELF avrdude: input file /usr/local/home2l/share/brownies/init.t861.elf auto detected as ELF avrdude: input file /usr/local/home2l/share/brownies/init.t861.elf auto detected as ELF AVR Part : ATtiny861 Chip Erase delay : 4000 us PAGEL : PB3 BS2 : PB2 RESET disposition : dedicated RETRY pulse : SCK Serial program mode : yes Parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 10 4 0 no 512 4 128 4000 4000 0xff 0xff flash 65 6 64 0 yes 8192 64 128 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 1 0 4500 4500 0x00 0x00 signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00 calibration 0 0 0 0 no 1 1 0 0 0 0x00 0x00 Programmer Type : usbasp Description : USBasp, http://www.fischl.de/usbasp/ avrdude: set SCK frequency to 93750 Hz avrdude: AVR device initialized and ready to accept instructions avrdude: device signature = 0x1e930d (probably t861) avrdude: Note: flash memory has been specified, an erase cycle will be performed. To disable this feature, specify the -D option. avrdude: erasing chip avrdude: set SCK frequency to 93750 Hz avrdude: reading input file /usr/local/home2l/share/brownies/init.t861.elf for hfuse with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte hfuse ... avrdude: 1 byte of hfuse written avrdude: verifying hfuse memory against /usr/local/home2l/share/brownies/init.t861.elf avrdude: 1 byte of hfuse verified avrdude: reading input file /usr/local/home2l/share/brownies/init.t861.elf for efuse with 1 byte in 1 section within [0, 0] avrdude: writing 1 byte efuse ... avrdude: 1 byte of efuse written avrdude: verifying efuse memory against /usr/local/home2l/share/brownies/init.t861.elf avrdude: 1 byte of efuse verified avrdude: reading input file /usr/local/home2l/share/brownies/init.t861.elf for eeprom with 50 bytes in 1 section within [0, 0x31] using 13 pages and 2 pad bytes avrdude: writing 50 bytes eeprom ... Writing | ################################################## | 100% 0.56 s avrdude: 50 bytes of eeprom written avrdude: verifying eeprom memory against /usr/local/home2l/share/brownies/init.t861.elf Reading | ################################################## | 100% 0.04 s avrdude: 50 bytes of eeprom verified avrdude: reading input file /usr/local/home2l/share/brownies/init.t861.elf for flash with 1972 bytes in 2 sections within [0, 0x7d1] using 32 pages and 76 pad bytes avrdude: writing 1972 bytes flash ... Writing | ################################################## | 100% 1.51 s avrdude: 1972 bytes of flash written avrdude: verifying flash memory against /usr/local/home2l/share/brownies/init.t861.elf Reading | ################################################## | 100% 1.06 s avrdude: 1972 bytes of flash verified avrdude done. Thank you. [root@home2l-admin ~/admin]# [root@home2l-admin /]# home2l-brownie2l home2l-brownie2l 1.2-2 (2023-04-19) by Gundolf Kiefer [home2l-brownie2l] DEBUG-1 (/common/env.C:712): Main configuration file is '/usr/local/home2l/etc/home2l.conf'. [home2l-brownie2l] DEBUG-1 (/common/env.C:717): br.gpio.oa_win_right.03.invert = true [home2l-brownie2l] DEBUG-1 (/common/env.C:717): br.link = = [home2l-brownie2l] DEBUG-1 (/common/env.C:717): br.serveSocket = brownies-drv [home2l-brownie2l] DEBUG-1 (/common/env.C:717): debug = 1 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): home2l.arch = amd64 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): home2l.buildDate = 2023-04-19 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): home2l.config = /usr/local/home2l/etc/home2l.conf [home2l-brownie2l] DEBUG-1 (/common/env.C:717): home2l.os = Debian [home2l-brownie2l] DEBUG-1 (/common/env.C:717): home2l.version = 1.2-2 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): location.latitudeN = 50.14978 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): location.longitudeE = 8.65877 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.etcDir = /usr/local/home2l/etc [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.execName = home2l-brownie2l [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.execPathName = home2l-brownie2l [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.instanceName = brownie2l [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.machineName = home2l-admin [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.pid = 11230 [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.rootDir = /usr/local/home2l [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.tmpDir = /usr/local/home2l/tmp [home2l-brownie2l] DEBUG-1 (/common/env.C:717): sys.varDir = /usr/local/home2l/var Connected to '/usr/local/home2l/tmp/brownies-drv' (local socket). Read database file '/usr/local/home2l/etc/brownies.conf'. brownie2l> open 7 007 new Device: ATtiny861 (t861) Firmware: init v1.2-2 Features: maintenance Config: brownie2l> program mat1x7.t861.elf Segments in '/usr/local/home2l/share/brownies/mat1x7.t861.elf': FLASH : 0a00 - 13f2 (2546 bytes) (SRAM) : 0060 - 011d (189 bytes) (EEPROM): 0000 - 0032 (50 bytes) (Re-)program FLASH of device 007 with this? (y/N) y Flashing device 007 with '/usr/local/home2l/share/brownies/mat1x7.t861.elf' ... 0a00 - 13f2 (2546 bytes) ... verifying ... OK brownie2l> boot -o Switching device 007 to OPERATIONAL firmware (block 0x28, adr=0x0a00) ... Activating and rebooting ... OK brownie2l> s -v 007 new mat1x7 v1.2-2 (t861) Device: ATtiny861 (t861) Features: timer notify matrix(1x7) Config: osccal=139 brownie2l> [root@home2l-admin /]# --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii [2] --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Disposition: attachment; filename=error.log Content-Type: application/octet-stream; x-unix-mode=0644; name="error.log" Content-Transfer-Encoding: 7bit avrdude: Version 7.3 Copyright the AVRDUDE authors; see https://github.com/avrdudes/avrdude/blob/main/AUTHORS System wide configuration file is /usr/local/etc/avrdude.conf User configuration file is /root/.avrduderc User configuration file does not exist or is not a regular file, skipping Using port : /dev/cuau0 Using programmer : usbasp Setting bit clk period: 10.0 us avrdude: usbOpenDevice(): found USBasp, bus:device: 0:2, serial_number: avrdude usbasp_open() error: cannot find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp' avrdude main() error: unable to open port /dev/cuau0 for programmer usbasp avrdude done. Thank you. --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii [3] --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Disposition: attachment; filename=usb.dump Content-Type: application/octet-stream; x-unix-mode=0644; name="usb.dump" Content-Transfer-Encoding: 7bit 18:41:16.460181 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.460680 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.460686 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.461069 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.461075 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 01 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.461572 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 1C 03 77 00 -- -- -- -- -- -- -- -- -- -- -- -- |..w. | flags 0 <0> status 0xca1a1 18:41:16.461576 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 01 03 09 04 1C 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 28 bytes flags 0 <0> status 0xea1a3 18:41:16.463070 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=28,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 28 bytes 0000 1C 03 77 00 77 00 77 00 2E 00 66 00 69 00 73 00 |..w.w.w...f.i.s.| 0010 63 00 68 00 6C 00 2E 00 64 00 65 00 -- -- -- -- |c.h.l...d.e. | flags 0 <0> status 0xea1a1 18:41:16.463078 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.463574 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.463579 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.464069 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.464075 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 02 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.464571 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 0E 03 55 00 -- -- -- -- -- -- -- -- -- -- -- -- |..U. | flags 0 <0> status 0xca1a1 18:41:16.464575 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 02 03 09 04 0E 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 14 bytes flags 0 <0> status 0xea1a3 18:41:16.465369 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=16,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 14 bytes 0000 0E 03 55 00 53 00 42 00 61 00 73 00 70 00 -- -- |..U.S.B.a.s.p. | flags 0 <0> status 0xea1a1 18:41:16.465374 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.465816 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.465820 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.466359 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.466364 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.466859 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.466864 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.467359 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.542287 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.542784 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.542790 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.543358 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.543363 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 01 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.543859 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 1C 03 77 00 -- -- -- -- -- -- -- -- -- -- -- -- |..w. | flags 0 <0> status 0xca1a1 18:41:16.543864 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 01 03 09 04 1C 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 28 bytes flags 0 <0> status 0xea1a3 18:41:16.545297 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=28,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 28 bytes 0000 1C 03 77 00 77 00 77 00 2E 00 66 00 69 00 73 00 |..w.w.w...f.i.s.| 0010 63 00 68 00 6C 00 2E 00 64 00 65 00 -- -- -- -- |c.h.l...d.e. | flags 0 <0> status 0xea1a1 18:41:16.545304 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.545800 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.545805 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.546358 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.546363 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 02 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.546858 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 0E 03 55 00 -- -- -- -- -- -- -- -- -- -- -- -- |..U. | flags 0 <0> status 0xca1a1 18:41:16.546863 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 02 03 09 04 0E 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 14 bytes flags 0 <0> status 0xea1a3 18:41:16.547761 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=16,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 14 bytes 0000 0E 03 55 00 53 00 42 00 61 00 73 00 70 00 -- -- |..U.S.B.a.s.p. | flags 0 <0> status 0xea1a1 18:41:16.547766 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.548358 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.548363 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 00 00 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.548858 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 18:41:16.548863 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xca1a3 18:41:16.549358 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xca1a1 18:41:16.549362 usbus0.2 SUBM-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 0000 80 06 00 03 09 04 04 00 -- -- -- -- -- -- -- -- |........ | frame[1] READ 4 bytes flags 0 <0> status 0xea1a3 18:41:16.549858 usbus0.2 DONE-CTRL-EP=00000080,SPD=LOW,NFR=2,SLEN=4,IVAL=0,ERR=0 frame[0] WRITE 8 bytes frame[1] READ 4 bytes 0000 04 03 09 04 -- -- -- -- -- -- -- -- -- -- -- -- |.... | flags 0 <0> status 0xea1a1 48 packets captured 48 packets received by filter 0 packets dropped by kernel --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 --- PGP-Key: CDE74120 =E2=98=80 mobile: +49 160 7568212 computing @ chaos claudius --Apple-Mail=_A0647609-88BC-42ED-A972-7C008529201F-- From nobody Thu Aug 22 10:52:31 2024 X-Original-To: freebsd-hackers@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 4WqKks4981z5SfV5 for ; Thu, 22 Aug 2024 10:51:33 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic305-19.consmr.mail.ir2.yahoo.com (sonic305-19.consmr.mail.ir2.yahoo.com [77.238.177.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4WqKkr3g8Nz4Q1Y for ; Thu, 22 Aug 2024 10:51:32 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="O/MIc446"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of anthony.pankov@yahoo.com designates 77.238.177.81 as permitted sender) smtp.mailfrom=anthony.pankov@yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724323889; bh=+EgrJeujpS3zKrNk3as416pIEQE6+AZhoBag4TwSJ2Y=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=O/MIc446uFckP+QSNADRQMf0yX/+ChcWZpxTFu/ZEpUV3PuzVai+i37LsBLnwQSOwJXR2K9iRMbHfzRRsVDrfyewGuOxfbMtdaNhfkowdbvqQUSKdg5GI1kdiSsqoUhK82bJnkZTPetk5WFsRA1KH8ltm4eNbRjz8ntghdEy+BEFw9n2OBAAdg8Ggp+Yu/4FeiSAI4iyHLML++Rix7t7/mboLM03tG1XDSaPmHPoajHhC0EQixRhLJ0ruoO3Tsu8LlpUDmDX3bBO2SFE6i/zo0XrO+nIMxyzNSeD40839UjIN3TYMwl6PoBdCA06O3chGFkck3r1zVnkbG3rExTBjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724323889; bh=z/EmfJ503hQcihglDxCnIVhTQkMSGCaOWa8SDL5Ujzq=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=eNFDUiE9wadVhYlBJMvIzQtQGbiuhncYtKZbSOPto4uAgBAQFoGWlYfSv8UoaTVHM2aFUUZAs1W5WOeYd5UMg0t0nLgMtGbMGKKO96Z5zBOsaY3U9bihU95V2uzvMPmMTtO5BCCC+Di106PB/xuv63xBLcmUsAa15GbDppRl8UR/fnA38al/JdEYMY2Vrsp8ibEV6xGzCArsWh9rX/LKGvfdzhmgcOvwHvSi7hv0jY8hD2Gyx1AZ9/eWwSWknQ5LoAI7499SlSWZczyLjb00lZX//ukFHu1PKxDeiqMXj20292giHso6mfMMjLCh3natrkxqcBL31qGHRnNrT2UB3Q== X-YMail-OSG: v3pp.NIVM1n5fSPdVSW3TEpzBealCKAA0Zwr_O_ShQaCOs8tCQZMKLFIaFz3tW6 IrMDzcsXAP7dFHmv_JWzsqSRlew.ORhOjLN_j7DmyOpNYPteXT2HhkctgLzsbZX3uR7XeOSK7UkH uPmE25Vz.aQHo_ZmJPEg_8_bsM7FC9Q.bzGsp5xCVMcwBvu.mZFTSu4HUpcgc_S6PNpUeaBlO1gw cAYN8kVTk6sT7TWmhERt4af3.Pis5MLnZDJDJsPcWZmqYl4_mH90hfq9Y2kExIfDRa8lewSeyCdC pN0H3AuAte3w_SCTJCdFAB4lC1CCjwEsomp9kQcPIZRJ5cQkrL444UPqTbryyH7BiEVAvwXfreEu .88zOJla1P6KTEiDFKnsqPTFPfMdQuvN1N2fMj_PHWFXV1HOdSO1Hb_8XI.gQGuS4UowRIsGcjjt 7ViAf1bRgxdnsSLlFhhcPbAvm4pgivfUJ76U3t6_KKV_gY2aGDmPCnEsnKxjjswsr4r1uyf9hBcc Dwj6eXSeNRFLI8nJfE9CrVdqz5IpIoL79wDzUoQGL0qBJ3Q1sWrpAMwK4l_lTHwmFNl404C9yjo3 Ep2Z29IR_NkeLrtVphwcLec9v__69J4gJS4ei2GixTTnAhtC9v3QvpWlGDrd77G2uPDU6OE5c__B bNRP5EmeuxcPcoyL0zIDPHKPDXQYjX2ITvuhUQ8gA6cJfnuoych7Coa3nQ4qXLIbQODbkZmc752L EcqalQ.a04pcJPnbHKL1x0iZH.9.KcCxXaAwXYVJ_tTe2Sh9FEWMK1FqvkF_h4Wkc0HIOymyiwli W5nvwUKr.ekek9ZMjMElUFsxPcWFXODGKz5iV90.t_BwYWaPB7Vyck4KrxppP2gpr2Swa4pxG3.E CU3ocGfiDB5TGbZSKX.AZLktZoAEh85yN6DMxU4ILEV_1MdGE3aacUD1GEbj7mDB0KUwEE_3akvD hOjJxTjCUefNHhRaCEGQKcNRgLVWVgyLkQIWwAB3Bc5Yh_QHL0kBXCsGxydB_yQaUJMRGK2IrqV6 8JrpQGgLuKtk1VgW.Wp4muk7hHFA_JggSuGBa7l1m1itq7yFOkuJZwtgwrnNiubbHr8JY7MuCeV8 _xKdbCcFXkxzEvvGcbmynDkK8zb4tFJoD0Z.s0darIxbzIgMTu1ATGHJf24FAqwp4.Z2CqrZyvcU 56AHrONUI_GvvngMyUppWUBpNfNPt621ZlL3tmNenIycL9zcvImlfk.eZlC.iBGUM3rBviArJ50V Xdnh2ZzEnfuKg4zxYJEF1.WxJuF8ACSS7M4GUMsXMt5ozQW2g.XZ0rGy1ojLI0k3HK7OjVDrvh1n frdZs5GYWErL1A12GB1ZMzDw4WcudqDe2r041gZypbr4KJPktCJVV6wjQzgRyfeELw1bUYlLNLJM Duccy8yYfnpWvWqttEyRuIuTruTn9D4_CjHszb_0ThdQrik.zgmXx1Zc7tXhvYiXxJMcymmHIOlH A7bX_O.YsWYJylZtrprxWWJ4mSqev41TQXtkJZkJRvz3FmJo_3dJd3YFJ7lnQ_CcWTfFaZmaRQKY _tlCWMI6ZV080w.tQjZJksgJnrN4Ukkl_1.U5u6CRxf3KG5ej4nhga3wWOxqI3LKD_5EDEQmbMRK Au4IbMMLJKCtZ3nQbm6FVcjDxjWhJe1686aVkkdZItbPJ2x7TfSR1MZyq_XN2F.n5Q7Uj8XxkIPr 1vAcyF9h8qdDvjaAoEBWidR4IJTM7Qrg1upzWpI83XkQG9mgQJtKPP5mW3dxgsJZz_mSKxK4ovnN 8RcmhMm9nHwDllp239HHVlkdiZSzFYG07I9dFjK_D4lrGcj69qt3b14i80L4NNDpC6VT_X1lb4vl OqUgLpjJVkjmH_7Y6Kgwm3X9Vr29WQNEylksjkQ_eYOZUZjqQG5hetOUTlE.ILcOC4vt3dt62lR7 qw6GZQOgeHEe0crtxiC7Y4rko93VYS1TLdO5wI.uH.xvdRR0XAYgwkT58hmYL5Fs_ABXvBTtb3wG r1ymEuxUWLWHskGcZK9W.nrwH6WJ8Mmm54rUb2QlTMP67hjKz.HAkdyNDA6SYd7bBG3ZAvPdBUpI kBFoR83FjWrGZBvdjgA0zSmwiHyg7tBa3QYS_g.fGAeZW6we5PzNo62Sl5uGsGoUYc5kmogFMczw kZoETOj27aHpUhAdudW.UGzQNxNie_LImOGTA X-Sonic-MF: X-Sonic-ID: 7dcada22-a38f-4b19-b34c-1f6cba6f125e Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Thu, 22 Aug 2024 10:51:29 +0000 Received: by hermes--production-ir2-6664f499fc-9knsr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 560a429ad7c4ef4ba30bde03a98858b8; Thu, 22 Aug 2024 10:51:25 +0000 (UTC) Date: Thu, 22 Aug 2024 13:52:31 +0300 From: Anthony Pankov Message-ID: <1781435895.20240822135231@yahoo.com> To: freebsd-hackers@FreeBSD.org Subject: makefs -t ffs makes too large image List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <1781435895.20240822135231.ref@yahoo.com> X-Mailer: WebService/1.1.22544 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[77.238.177.81:from]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; DKIM_TRACE(0.00)[yahoo.com:+] X-Rspamd-Queue-Id: 4WqKkr3g8Nz4Q1Y Hello, There is no much info about makefs so I ask here. I've tried to make UFS image via `makefs` of a directory sized 500Mb and get file of 1200Mb. Is it a bug or feature? Is it related to source files that lies on ZFS while making UFS image? #makefs -t ffs -B little -o label=rootfs -o version=2 -o softupdates=0 image/rootfs.ufs installed Calculated size of `image/rootfs.ufs': 1264320512 bytes, 14974 inodes Extent size set to 32768 image/rootfs.ufs: 1205.8MB (2469376 sectors) block size 32768, fragment size 4096 using 2 cylinder groups of 866.31MB, 27722 blks, 11136 inodes #du -hcd 1 installed/ 512B installed/media 512B installed/tmp 512B installed/mnt 2,4M installed/sbin 259K installed/var 512B installed/dev 99K installed/libexec 835K installed/bin 384M installed/usr 9,7M installed/rescue 676K installed/etc 512B installed/net 5,0K installed/root 512B installed/proc 9,4M installed/lib 90M installed/boot 497M installed/ 497M total # tunefs -p image/rootfs.ufs ... tunefs: maximum blocks per file in a cylinder group: (-e) 8192 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 0 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs P.S. FreeBSD version 14-STABLE -- Best regards, Anthony Pankoff mailto:anthony.pankov@yahoo.com From nobody Thu Aug 22 14:55:35 2024 X-Original-To: freebsd-hackers@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 4WqR8f6D9Jz5T4Wg for ; Thu, 22 Aug 2024 14:55:46 +0000 (UTC) (envelope-from SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WqR8d49Q1z4pjH for ; Thu, 22 Aug 2024 14:55:45 +0000 (UTC) (envelope-from SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b=sQM5DW3+; dkim=pass header.d=quip.cz header.s=private header.b=lhDdXp3z; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A9A06D78A9 for ; Thu, 22 Aug 2024 16:55:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1724338536; bh=XabME0JTzxbB+r0dgvNtygbZJsGAVzUOzs7BCJUHDK4=; h=Date:Subject:To:References:From:In-Reply-To; b=sQM5DW3+cqag/Z1TlSpl3U+DbDRsQlWmZ4xxRs4Gk6w4Z6HfpS5e1bL+m3D8FzsaT nD4uxwjZdoyCPwJianhr7t5p1cyvCTqKJ610Jlbwyt23M5mQ9No1hdXG3GvWFfy/PV 1tqbw8umwkeH/KPKoGh3jwepCqobvz3g6ropoFxs= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 946D6D7897 for ; Thu, 22 Aug 2024 16:55:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1724338535; bh=XabME0JTzxbB+r0dgvNtygbZJsGAVzUOzs7BCJUHDK4=; h=Date:Subject:To:References:From:In-Reply-To; b=lhDdXp3zdRg44jYvMhvXRgJbu3mXTs1qiyWqlt8JYuMfYMj5AAHEJxRsR1Am8Fj/y OFvwXKhVFJp5VVIh3ZMeVRquSI1tOOlXV0B58Pvsk1BB2qSM3Lwvnse9X3MrVm7yPP IY5yVccSbu45Xgny+N+QEBH1THTQytBD6F+8RZtc= Message-ID: Date: Thu, 22 Aug 2024 16:55:35 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: makefs -t ffs makes too large image To: freebsd-hackers@freebsd.org References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> Content-Language: cs-Cestina From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <1781435895.20240822135231@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[quip.cz]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4WqR8d49Q1z4pjH On 22/08/2024 12:52, Anthony Pankov wrote: > Hello, > > There is no much info about makefs so I ask here. > > I've tried to make UFS image via `makefs` of a directory sized 500Mb and get file of 1200Mb. > Is it a bug or feature? Is it related to source files that lies on ZFS while making UFS image? > > #makefs -t ffs -B little -o label=rootfs -o version=2 -o softupdates=0 image/rootfs.ufs installed > > Calculated size of `image/rootfs.ufs': 1264320512 bytes, 14974 inodes > Extent size set to 32768 > image/rootfs.ufs: 1205.8MB (2469376 sectors) block size 32768, fragment size 4096 > using 2 cylinder groups of 866.31MB, 27722 blks, 11136 inodes > > #du -hcd 1 installed/ > > 512B installed/media > 512B installed/tmp > 512B installed/mnt > 2,4M installed/sbin > 259K installed/var > 512B installed/dev > 99K installed/libexec > 835K installed/bin > 384M installed/usr > 9,7M installed/rescue > 676K installed/etc > 512B installed/net > 5,0K installed/root > 512B installed/proc > 9,4M installed/lib > 90M installed/boot > 497M installed/ > 497M total > > # tunefs -p image/rootfs.ufs > ... > tunefs: maximum blocks per file in a cylinder group: (-e) 8192 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: space to hold for metadata blocks: (-k) 0 > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) rootfs Is it possible that you have enabled compression on source ZFS filesystem? Try to ad -A to you "du" command to see actual size of files, not compressed size on filesystem. Kind regards Miroslav Lachman From nobody Thu Aug 22 15:24:05 2024 X-Original-To: freebsd-hackers@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 4WqRmC0N1rz5T6Lh for ; Thu, 22 Aug 2024 15:23:07 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Received: from sonic313-20.consmr.mail.ir2.yahoo.com (sonic313-20.consmr.mail.ir2.yahoo.com [77.238.179.187]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4WqRmB3zxVz4sGB for ; Thu, 22 Aug 2024 15:23:06 +0000 (UTC) (envelope-from anthony.pankov@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724340183; bh=mDAPssDk7SY+dGgMNRU/1TMN4IqPoL1Ji7DqMuOB6Ts=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject:Reply-To; b=MqforLW60qBZpaarMJq8Zl2v3YUJSVoxlR1T2UpWDHPOpdyS3VOnGqQrrfqLkKxBURrVXdeCP2oxnsLcf04NaBn+ejqRf2JD3nUulJZFzujb7GBpKei/RyQddXwkodRAKczmV+XotVtJ5YFWY/Nrkt5+WMIe7O61a7ppWUW9vI9AdEvcwxjy0016a7tEmME2xc6VmsC4MVVFxGqibEE3vsJKV4VTdABC17g28NsVs5C+UEtqbcBVUutQchT4cSTEctQA9+s0kn1c7QuNwz+sQfeXQ2JjYsq96xKtJmIZZcQscgZV+KMpcCG4jhZmcLiPqdcpYzuUe25bKd623NTAmA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1724340183; bh=wRzsjSmnPHgzGzzXCUeinmcOuO0Y+8tpOc9o0JkaV5a=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Le1n3hBihl+OmmBG/PxwqbXct0ywN/iDja8NT9Ff7xWue3oTHxL4TggEGeMB9F5z6uwgKl81EVEtzfm0T+MvuqlP5KYlUcFAGeV8j5coIs3V68sOzGFvQxrAE7rmDdccmBsJsFthfS4HEI+GvNB7HOJ6dXCNi7s3+NlNzFyGK9InmEhJ0UYtf+sPapSVPZwSxQYH8UxtVRXTY9CYlnBiHvQfBrjlrFR2SH52xQoG9gg5cbOOwL6RGVfOZeWRjtWs1K7WDL5vtzNie2ibl1XJbTFPYp5tk5sFJwWFSE/IGB6/eezICRaaZkg0usP4JqmOPgujhigZ07WsLDW3rcfe+w== X-YMail-OSG: 8NtCpmoVM1maQ_c86gkxeUEajTYkMpMyxSvIaaoGlZBFGKYyXCc7vB4tipYAYCi WUqtYY6X48fx.M1tTZWK1BvbX4sW_u5bFbR0rXr3TDzK7Dp1TtrlgXWlKGmuBMs0aoTehHG8U1HT NjEvs8QK5rptdJA_WJqr0hHgkKsGo43QFapUAjRSsW2krd5BtF.q9PQW3dFnb5KVA6CDlKKV.PB5 .mqVmoNpwO5iWn6L9Da62jIiOyT22xGwdJkBL._iRxIFDxb10nrsphPr4ifBmP6UT7qmqBD2BJoy .xNH20YcT0QuSHsrxXE8bLLEh2fJZ2SmUqRCK5RwO66P1cLSAAfw8ISh2F1NzQfNDSh28yjy.jDk stkZc6LAr6kpvQ0eNZKuQ7iT9mrNAP0qBHjmX0zgX.7mLNuiMyBa1XR6p48n38Ylp1f.4qLMSUw3 G7h46Csec_RYMdpYx8kQa1VdcHQApsN8cnp.WJnJ8I8TfRCR.D25u5aZLFMM0TmunrIyczYAPwLl Vrgrolyo_SNgqi7HmaJSUjEDymFNCjg2Yos25pWoy_PKPlU6dRrcMqHDossDSPwd0MpxgjBqD6Aq xQ8hbw5beqnpx9HBSzfDi2BmQ.fL4DqqYJtvKOvEqVuwgAtzrtHb9d6p3LY1htiaTQRgLvJJOQeL 9I3fzev.jQnoHFAhH44W7edvIpncGk8xBzfHSay6L8SU_OjTkBT4aXt4cHHUvZZZeTucUx33W1N9 JsmEw.J5v.AMbs_REL51MbFmwM.dQwlzXhQjLlJSWW0FX9e_aGsqIayKG3Q2WZTZEuWECGmpoJrm LG_dOGhsxRVWkPbtFHgMO2OeFl3EpyZUug4jJdUh1_twHjwwwzjBX6od0k90DtcQuemt4DpJgb1g zf1DEzUT1oafcE23Eg1IrKMAKxNrWyK5ToRCSCZpQ1URv8O3ymPw6F99MtXR3PscuUpSZtZ6BIpv Q5ECHw4p5CU3d_ziHgfzzquXiSCeZ847CVfCMHcX2x2jmh.u2dlZJzNvS6jSFMT82pibtBIZjuUN 5aShsJBjnaQ39faOG9AYFnRoPQgUt_TMUorQgWzuUEEtGr1MDEZZLdnhncq8xkd6FBaE2Sgyt6ci Pb4tXCKydS8scOMPEABhqsgzA0cwh.Cm172JpXV2ae2HLu_7Wo5KBNR3v7Y4drRV3rIR8n6f7DYr kcMiio0U47HiVI2BSgbP6TZoZiVssZAru__2USiPKeth9guJjiKDh3TvYLniwLBPalduKyKuh96X UBTR_CAv86CfXDhxsjO4rmqLxC1tT.zwsx3aDb7XZrEvFoT_Cnyy4X5TkawaCqGWyR1DRHyKsN3x IClUrc3X0glLYsS7fujDRYsQ8poN.YEScYqgE3Zf31kDvlI36YTaW3zbBKkl.bTPWxigkA5qR8yq ri3fnlL76csjAU6kN2Pe_UirpQu8xEqsTP65aALcejlAaSB9..Y7tGfaPVzH8GelGYTAdh9SwOHY gqD8LSIaFUyYFV.m16RxPEcyxB4LJvXocrKd2BVAktm_MZWchiXLxqKHiAcbOhSbI2GC05qoKylj DKDLRGxAhuMUB7bJ0CPyp77_U4zFEMzc50QKnvtqwaCZohJUVxTkjKkJXvW1ldWJOq4boagrgDH_ o46oQqNlofNFH024zhTzyPxqKFDRDrFElDd291SKrxmYDE9.5L7hLA3oYkreofK9EHzMyvXIctC. f2yX4OeIHGRIIShQvwFMCk2TvEh_.._UV6p8z_XZb8SuoUh4T0J9iwCrueGh1ZS_kKwDtzA20g7q pi.dI2KQ_XNub8CTfSCR93RHj98h_X4etMM3.vR_OcukcGplNqSqq4Nu7kLcUTtlR_Y3TUbz8u01 bxBdgoM2GCnH..Tg8D6FtMf9F34rNt.ZqoWGGm0AMGIz_GuSrnVpxp.ie_fuSC5i4HJkzu66cC_R 6avRkikeyAW66inovx.w21KTXqnvNBDc6TvOhntA70JKRGvrUUebFZ.xBHeYyPmk_p5JFc9RFHzb iLxsKoYp9jKc9P9EVNDwWC90MTEdHkkfBJyHMH8O_G8QaAkP0osD3w8y4j5I22_Gc7NJCdbp_JV0 9Ddj18l.jKHmR.ApK9fBlNreUzjZldOkC927x.vrOHKb3hbURWNewNHwtnxDcS_tQ1SwYJY2AxV9 vgoN.6WRHZ2btZqOSUXyRxW1zD4liBShGTFDDrsfRRkoHxAzR6z3JUXLt0zZ5ebWJN_O3fN5IJ1a h9HnO599IFPVqqirdTkXSeeHIspiXNIXK X-Sonic-MF: X-Sonic-ID: 7eb509e7-6156-4ebd-b755-70a9aa912252 Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Thu, 22 Aug 2024 15:23:03 +0000 Received: by hermes--production-ir2-6664f499fc-l95lq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7017b3ee94a8f6f1c301693f14eda9d0; Thu, 22 Aug 2024 15:22:59 +0000 (UTC) Date: Thu, 22 Aug 2024 18:24:05 +0300 From: Anthony Pankov Message-ID: <334195982.20240822182405@yahoo.com> To: Miroslav Lachman <000.fbsd@quip.cz>, freebsd-hackers@freebsd.org Subject: Re: makefs -t ffs makes too large image In-Reply-To: References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.22544 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34010, ipnet:77.238.176.0/22, country:GB] X-Rspamd-Queue-Id: 4WqRmB3zxVz4sGB Hello Miroslav, You are genius! But the situation is a very frustrating. It is a default system and I did nothing to turn the compression on. So I was absolutely sure that compression is off. I'm sorry. Nevertheless having compression on by default is a very weird decision and is fully unexpected for me. I've never seen a big warning about default value of this vital parameter will be inverted. On 12 -STABLE: # zfs get compression NAME PROPERTY VALUE SOURCE ps2 compression off default On 14-STABLE # zfs get compression NAME PROPERTY VALUE SOURCE tank compression on default tank/bsdsrc compression on default Thank you. Thursday, August 22, 2024, 5:55:35 PM, you wrote: > On 22/08/2024 12:52, Anthony Pankov wrote: >> Hello, >> > There is no much info about makefs so I ask here. >> > I've tried to make UFS image via `makefs` of a directory sized 500Mb and get file of 1200Mb. >> Is it a bug or feature? Is it related to source files that lies on ZFS while making UFS image? >> > #makefs -t ffs -B little -o label=rootfs -o version=2 -o softupdates=0 image/rootfs.ufs installed >> > Calculated size of `image/rootfs.ufs': 1264320512 bytes, 14974 inodes >> Extent size set to 32768 >> image/rootfs.ufs: 1205.8MB (2469376 sectors) block size 32768, fragment size 4096 >> using 2 cylinder groups of 866.31MB, 27722 blks, 11136 inodes >> > #du -hcd 1 installed/ >> > 512B installed/media >> 512B installed/tmp >> 512B installed/mnt >> 2,4M installed/sbin >> 259K installed/var >> 512B installed/dev >> 99K installed/libexec >> 835K installed/bin >> 384M installed/usr >> 9,7M installed/rescue >> 676K installed/etc >> 512B installed/net >> 5,0K installed/root >> 512B installed/proc >> 9,4M installed/lib >> 90M installed/boot >> 497M installed/ >> 497M total >> > # tunefs -p image/rootfs.ufs >> ... >> tunefs: maximum blocks per file in a cylinder group: (-e) 8192 >> tunefs: average file size: (-f) 16384 >> tunefs: average number of files in a directory: (-s) 64 >> tunefs: minimum percentage of free space: (-m) 8% >> tunefs: space to hold for metadata blocks: (-k) 0 >> tunefs: optimization preference: (-o) time >> tunefs: volume label: (-L) rootfs > Is it possible that you have enabled compression on source ZFS filesystem? Try to ad -A to you "du" command to see actual size of files, not compressed size on filesystem. > Kind regards > Miroslav Lachman -- Best regards, Anthony From nobody Thu Aug 22 15:39:03 2024 X-Original-To: freebsd-hackers@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 4WqS6g6NJQz5T7wp for ; Thu, 22 Aug 2024 15:39:07 +0000 (UTC) (envelope-from SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WqS6f4pKYz4tSJ for ; Thu, 22 Aug 2024 15:39:06 +0000 (UTC) (envelope-from SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=quip.cz header.s=private header.b="dGslqz/X"; dkim=pass header.d=quip.cz header.s=private header.b=nTA0FPvT; dmarc=none; spf=none (mx1.freebsd.org: domain of "SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz" has no SPF policy when checking 94.124.105.4) smtp.mailfrom="SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz" Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id B5C2BD78B5 for ; Thu, 22 Aug 2024 17:39:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1724341144; bh=+s2+05/9xFlbxVs+aGyZresDvLE6lbRHJUvT+l1YmyU=; h=Date:Subject:To:References:From:In-Reply-To; b=dGslqz/Xn2FnM5hmcmTtHDNyK1waLtraAasbIb36H+tDVx1AwlM6ogJ9z7BSoIVRm 3uc7xcRUDMR3lUGEXxf3DFvLmj8qh0BRfW0vKjyymuxe+2XMbxVaM/VStLL3GjbCK8 yAAV+5bmjedwL4b1C+/oHDifDPPliONwgbwikeL8= Received: from [192.168.145.49] (ip-89-177-27-225.bb.vodafone.cz [89.177.27.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id ECBB0D78A9 for ; Thu, 22 Aug 2024 17:39:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quip.cz; s=private; t=1724341143; bh=+s2+05/9xFlbxVs+aGyZresDvLE6lbRHJUvT+l1YmyU=; h=Date:Subject:To:References:From:In-Reply-To; b=nTA0FPvT4qBqyVL6EAwEAZomre/gCzKGX9QR7x+IUCrhmQ5Ue5c3tib29UY/fOfPR cpTiIWUQ3GAiSJDSIzt5b8CXUjzBJEDrfS0aMvBQPpM/IyKCVtPqtjguubLmN5L1ru ksxJMpKsYmEpspMx1FuuI1/dLj4izpp++beWKgIM= Message-ID: <64161a04-57b2-44ab-9e7e-b313a7d50a08@quip.cz> Date: Thu, 22 Aug 2024 17:39:03 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: makefs -t ffs makes too large image To: freebsd-hackers@freebsd.org References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> <334195982.20240822182405@yahoo.com> Content-Language: en-US From: Miroslav Lachman <000.fbsd@quip.cz> In-Reply-To: <334195982.20240822182405@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_ALLOW(-0.20)[quip.cz:s=private]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[quip.cz]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=MuLc=PV=quip.cz=000.fbsd@elsa.codelab.cz]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[quip.cz:+] X-Rspamd-Queue-Id: 4WqS6f4pKYz4tSJ On 22/08/2024 17:24, Anthony Pankov wrote: > Hello Miroslav, > > You are genius! > > But the situation is a very frustrating. It is a default system and I did nothing to turn the compression on. > So I was absolutely sure that compression is off. > > I'm sorry. > Nevertheless having compression on by default is a very weird decision and is fully unexpected for me. I've never seen a big warning about default value of this vital parameter will be inverted. 100 people, 100 tastes :) In fact, the compression is the first thing I turn on on each newly created pool (if it isn't the default). Kind regards Miroslav Lachman From nobody Thu Aug 22 17:39:26 2024 X-Original-To: freebsd-hackers@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 4WqVnd6h0bz5TKWP for ; Thu, 22 Aug 2024 17:39:33 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from fhigh8-smtp.messagingengine.com (fhigh8-smtp.messagingengine.com [103.168.172.159]) (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 4WqVnd540Lz47Ky for ; Thu, 22 Aug 2024 17:39:33 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=yx6SC7tX; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="q g6HcRq"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 103.168.172.159 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from phl-compute-05.internal (phl-compute-05.nyi.internal [10.202.2.45]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 1D24D1151BDA for ; Thu, 22 Aug 2024 13:39:33 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Thu, 22 Aug 2024 13:39:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1724348373; x=1724434773; bh=r5jXWNt//YZShGFP9lvuxr+KxKFKCdnoA77trnXba0k=; b= yx6SC7tX3a1ggh/C/+nJ8P5tCGYqvMLmqnkKFJ/HhE0RrdOYaK+bLl6yAI5ZkAmZ RI5IDqRocwqbjMQ//ElXWxFjF9/37qOYBTuyshPGpgwtKhj9xt3OeSnVDtzKUZdX 6yXiMXEQjkdZywFtmjeyLEP05nRKj0IVsVud4ACbXwSWBSekLKWX1fwfez/WVMFK bfzc1vNdSUpTD+uCqU5/EqnVOEpg+yZe9918Z5ba5YJeJK88k6+d8l14rKmEjtux 7GY+4gak+VroQwMZM0lJwXtAfB04i6Wirt8R7ifQ+MfVfwudA618HAhpPnA6sKkU uI1YFahDy7NxF9NoohrJKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1724348373; x= 1724434773; bh=r5jXWNt//YZShGFP9lvuxr+KxKFKCdnoA77trnXba0k=; b=q g6HcRqdaU7zba0H9bztjOdrEa2IkBrYUUts+YFLx/3E9T6hXWuT8czZgmp5ztDN1 vbXFduZCRil+r2qC+EW2qnZkP99hH7C/ElKD6AUOVDzN952xgeoc4S/UhvSMTB5q vVYBwF6U6EnuREYNG8z27o5g2M+46jN9Ldo6ibFYSt6yCvR530Atb0rN7HqlBMR/ Pw8MbIaQ999KYSTgojnP9NCo8OJawM5bx5+zjL2Vi7fNDPxUUbwoKOWSjv2V5yTQ IL2bsdmWcUMrZ6q7Gxlc3fRb405Q68TeqzRKLFCxe98dXJ/4MF44hJog96iuAHaT EaBxJ7w7Xx8YBVlVr1PbA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddruddvtddguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculd dqhedmnecujfgurhepkfffgggfuffvfhfhjggtgfesthejredttddvjeenucfhrhhomhep jghurhhiucfrrghnkhhovhcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeenucggtffrrg htthgvrhhnpeefteehtddtieeuhfevjeelkeeuhfeffeekgeeggffffeejleekieehtdet geeuteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe ihuhhrihesrggvthgvrhhnrdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepshhm thhpohhuthdprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggssh gurdhorhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 22 Aug 2024 13:39:31 -0400 (EDT) Message-ID: <70579701-7457-46b1-9329-a51eddec51de@aetern.org> Date: Fri, 23 Aug 2024 00:39:26 +0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: makefs -t ffs makes too large image To: freebsd-hackers@freebsd.org References: <1781435895.20240822135231.ref@yahoo.com> <1781435895.20240822135231@yahoo.com> <334195982.20240822182405@yahoo.com> Content-Language: en-US From: Yuri Pankov In-Reply-To: <334195982.20240822182405@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-Spamd-Result: default: False [-0.39 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:103.168.172.128/27]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm1]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US]; local_wl_from(0.00)[yuri@aetern.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEFALL_USER(0.00)[yuri]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+] X-Rspamd-Queue-Id: 4WqVnd540Lz47Ky Anthony Pankov wrote: > Hello Miroslav, > > You are genius! > > But the situation is a very frustrating. It is a default system and I did nothing to turn the compression on. > So I was absolutely sure that compression is off. > > I'm sorry. > Nevertheless having compression on by default is a very weird decision and is fully unexpected for me. I've never seen a big warning about default value of this vital parameter will be inverted. > > On 12 -STABLE: > > # zfs get compression > NAME PROPERTY VALUE SOURCE > ps2 compression off default > > On 14-STABLE > > # zfs get compression > NAME PROPERTY VALUE SOURCE > tank compression on default > tank/bsdsrc compression on default It came in with the following openzfs commit and probably no one really noticed as installer turns on compression by default, so I was going to say it was always that way until I looked up the change :-) commit 56fa4aa96eb3875f254e93eaef646ea20ba187f9 Author: Rich Ercolani Date: Thu Mar 3 13:43:38 2022 -0500 Default to ON for compression A simple change, but so many tests break with it, and those are the majority of this. Reviewed-by: George Melikov Reviewed-by: Brian Behlendorf Signed-off-by: Rich Ercolani Closes #13078 And it looks like it's in FreeBSD starting with 14.0: $ git branch -a --contains 56fa4aa96eb3875f254e93eaef646ea20ba187f9 * main remotes/origin/HEAD -> origin/main remotes/origin/main remotes/origin/pull/956/merge remotes/origin/releng/14.0 remotes/origin/releng/14.1 remotes/origin/stable/14 From nobody Fri Aug 23 02:40:46 2024 X-Original-To: freebsd-hackers@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 4WqkpH5plwz5V6Jx for ; Fri, 23 Aug 2024 02:40:55 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [IPv6:2604:3a00:2:1::2:13]) (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 4WqkpG4tr3z531j for ; Fri, 23 Aug 2024 02:40:54 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of fullermd@over-yonder.net designates 2604:3a00:2:1::2:13 as permitted sender) smtp.mailfrom=fullermd@over-yonder.net Received: from draco.over-yonder.net (c-174-180-135-60.hsd1.ms.comcast.net [174.180.135.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 4Wqkp73y86zCYJ for ; Thu, 22 Aug 2024 21:40:47 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4Wqkp65c9nz105y; Thu, 22 Aug 2024 21:40:46 -0500 (CDT) Date: Thu, 22 Aug 2024 21:40:46 -0500 From: "Matthew D. Fuller" To: freebsd-hackers@freebsd.org Subject: Announcing freebsd-rustdate Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/2.2.13 (2024-03-09) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.30)[-0.304]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:33069, ipnet:2604:3a00::/32, country:US]; RCPT_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[over-yonder.net]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WqkpG4tr3z531j Do you enjoy using freebsd-update to keep your systems fresh, but not so much enjoy the vacations you go on while waiting for it finish doing its thing? Ever wished there was something faster and way less widely tested you could use instead? Well, today's your lucky day! The performance of freebsd-update.sh has bothered me a number of times, so over the past few months I've been working on a re-implementation of it in Rust. It's fairly feature complete now, and seems to be working OK. I've been using it on multiple systems, and they're all still working. So, it's time for other people to see it now. I've setup a small site: https://rustdate.over-yonder.net/ that has a download of a current tarball (a pretty vanilla cargo workspace), a lot of information on usage, the differences from freebsd-update.sh, and some deeply unfair speed comparisons. It awaits your examination, and I await your feedback. Here's some quick summary points; see the site (or the built-in help) for more details: The basic commands (fetch/cron/upgrade/install) are roughly the same. There's fairly extensive built-in help for the commands and arguments. A number of parts can make use of multiple cores, so you can get some nice speedups if you have them. There are progress bars for most long-running operations. Manual conflict resolution and showing the details of pending upgrades are separate commands, so 'fetch' and 'upgrade' don't have any interactive elements. Just for a quick taste of the speed difference, with warm caches on my fairly powerful workstation, upgrading from 13.2-RELEASE to 14.0-RELEASE-p9 with the full source tree included takes under 2 minutes with freebsd-rustdate (well under 1 minute, if you disable fsync), compared to about half an hour for freebsd-update. I'm sure there's lots more testing it needs, so I'd be cautious about grabbing this and running straight ahead to upgrading your whole production fleet with it. But I'd love to know about what's missing or broken, so I can add or fix it. Or about what's working right, so I can break it. It's worked well for me, so it's probably not _completely_ broken. I've done my best to make it roughly equivalent to the .sh, but tracking through some the logic in there is kinda twisty. I don't have any insight into how it's all expected to work except for what I could glean from those sh-spelunking trips, so I expect there are still surprises lurking somewhere. In any event, I definitely want to thank Colin Percival and everyone else who's worked on the existing script and infrastructure over the years. I'm sure I'm not the only one who appreciates it. And I very much don't intend anything in this mail or on the site as any sort of slight against them; shell scripts are just slow. Of course, while I've done my best to work from the contents of the .sh, all the code in this is mine, so nothing in it is in any way Colin's fault, or anyone's but me[0]. [0] It's probably not my fault either. There's a small family of elves living in an old ATX case in my closet, who regularly put bugs into my code. So, really, just blame them. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From nobody Fri Aug 23 23:15:11 2024 X-Original-To: freebsd-hackers@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 4WrGBj1Lkrz5TfL0 for ; Fri, 23 Aug 2024 23:15:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WrGBh5N79z4kK8 for ; Fri, 23 Aug 2024 23:15:24 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-4f2c8e99c0fso729392e0c.1 for ; Fri, 23 Aug 2024 16:15:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724454923; x=1725059723; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=05XWdorI8OzwXdirHwP50IEq0PoXZss5jDbHtcBN0Tw=; b=MA7h/XboF1Me0twIfJHsa1tBKutDbb7tWrxJM9iZZtFboOIbvUODUqm3Vj3NWM9Wi8 EB1KmO6aT1YNg62NYAwOwAwre654a92LrxR01FnvN49mgJSEYnqcXvSsm7DBL2u2QYh/ JKxIF7VAOK69kz6oc1aNYosD2sTyyBPEHHoW2VyOp+psfxxCAmcdanMe7EFKK2/3Tawz aoAasspUIVeHq+w74GLB5HRTSDyuToKs/PYolVfQ2NPwqMu2ljZN3WfUj8K2Q6DPe2XX n2lSQT/Nwj0F53C/LJg+q6psSxzaqgovwcUS/aOUuWjFTUJnto8usEsPU0brxGwYs4RR owJA== X-Gm-Message-State: AOJu0YwMtVTDFF/xi7BUgoKgj753yYxtfncJwMR1gQd2N7cxT20ANiuV cOEoOkjNq7zt+EUsVruF2ttUf7yliaIL9OuibIRON+7kf3yY/CO3uDuHaoGJSVUnbZ0wmF35Y4Q y10ycM9TlXpzDfN+wRQEzLUViLLdV7w== X-Google-Smtp-Source: AGHT+IFnDL8zIbrlVxUxT42A64Uc6/yaeiDC/kHS9eYdo4amK4wXTAjW+T9Tw2gd2sVg+sIOMkUkkqzm7eka2mtahOw= X-Received: by 2002:a05:6122:ca4:b0:4ef:678e:8a90 with SMTP id 71dfb90a1353d-4fd1abf8f7cmr4880878e0c.3.1724454923276; Fri, 23 Aug 2024 16:15:23 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 23 Aug 2024 17:15:11 -0600 Message-ID: Subject: Re: Announcing freebsd-rustdate To: "Matthew D. Fuller" Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4WrGBh5N79z4kK8 On Thu, Aug 22, 2024 at 8:41=E2=80=AFPM Matthew D. Fuller wrote: > > Do you enjoy using freebsd-update to keep your systems fresh, but not > so much enjoy the vacations you go on while waiting for it finish > doing its thing? Ever wished there was something faster and way less > widely tested you could use instead? Well, today's your lucky day! > > The performance of freebsd-update.sh has bothered me a number of > times, so over the past few months I've been working on a > re-implementation of it in Rust. It's fairly feature complete now, > and seems to be working OK. I've been using it on multiple systems, > and they're all still working. So, it's time for other people to see > it now. > > > I've setup a small site: > > https://rustdate.over-yonder.net/ > > that has a download of a current tarball (a pretty vanilla cargo > workspace), a lot of information on usage, the differences from > freebsd-update.sh, and some deeply unfair speed comparisons. It > awaits your examination, and I await your feedback. > > > Here's some quick summary points; see the site (or the built-in help) > for more details: > > The basic commands (fetch/cron/upgrade/install) are roughly the same. > There's fairly extensive built-in help for the commands and arguments. > A number of parts can make use of multiple cores, so you can get some > nice speedups if you have them. There are progress bars for most > long-running operations. Manual conflict resolution and showing the > details of pending upgrades are separate commands, so 'fetch' and > 'upgrade' don't have any interactive elements. > > Just for a quick taste of the speed difference, with warm caches on my > fairly powerful workstation, upgrading from 13.2-RELEASE to > 14.0-RELEASE-p9 with the full source tree included takes under 2 > minutes with freebsd-rustdate (well under 1 minute, if you disable > fsync), compared to about half an hour for freebsd-update. > > > I'm sure there's lots more testing it needs, so I'd be cautious about > grabbing this and running straight ahead to upgrading your whole > production fleet with it. But I'd love to know about what's missing > or broken, so I can add or fix it. Or about what's working right, so > I can break it. > > It's worked well for me, so it's probably not _completely_ broken. > I've done my best to make it roughly equivalent to the .sh, but > tracking through some the logic in there is kinda twisty. I don't > have any insight into how it's all expected to work except for what I > could glean from those sh-spelunking trips, so I expect there are > still surprises lurking somewhere. > > > In any event, I definitely want to thank Colin Percival and everyone > else who's worked on the existing script and infrastructure over the > years. I'm sure I'm not the only one who appreciates it. And I very > much don't intend anything in this mail or on the site as any sort of > slight against them; shell scripts are just slow. Of course, while > I've done my best to work from the contents of the .sh, all the code > in this is mine, so nothing in it is in any way Colin's fault, or > anyone's but me[0]. > > > > [0] It's probably not my fault either. There's a small family of > elves living in an old ATX case in my closet, who regularly put > bugs into my code. So, really, just blame them. This looks awesome! I can't wait to try it out. I too get painfully bored by those long freebsd-update sessions. But it needs a couple of things: * Revision control. Are you going to commit it to Github or some other public repository? * Tests. One of the things I like best about Rust is its testing infrastructure, and one of the things that scares me most about freebsd-update is its total lack of tests. It has me afraid to change anything. We need to figure out how to get some test coverage here. I might be able to help. -Alan From nobody Sat Aug 24 03:52:19 2024 X-Original-To: freebsd-hackers@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 4WrNLN4sk8z5V3Ls for ; Sat, 24 Aug 2024 03:52:28 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from mail.infocus-llc.com (mail.infocus-llc.com [IPv6:2604:3a00:2:1::2:13]) (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 4WrNLN22gYz4FTJ; Sat, 24 Aug 2024 03:52:28 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Authentication-Results: mx1.freebsd.org; none Received: from draco.over-yonder.net (c-174-180-135-60.hsd1.ms.comcast.net [174.180.135.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.tarragon.infocus-llc.com (Postfix) with ESMTPSA id 4WrNLD64TrzCtY; Fri, 23 Aug 2024 22:52:20 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id 4WrNLC4lHYz116c; Fri, 23 Aug 2024 22:52:19 -0500 (CDT) Date: Fri, 23 Aug 2024 22:52:19 -0500 From: "Matthew D. Fuller" To: Alan Somers Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing freebsd-rustdate Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/2.2.13 (2024-03-09) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:33069, ipnet:2604:3a00::/32, country:US] X-Rspamd-Queue-Id: 4WrNLN22gYz4FTJ On Fri, Aug 23, 2024 at 05:15:11PM -0600 I heard the voice of Alan Somers, and lo! it spake thus: > > * Revision control. As a man of culture and taste, I'm naturally doing my work in bzr rather than git. Maybe I can try and get a real project setup over the weekend, but for now I've at least pushed my current trunk up to https://code.launchpad.net/~fullermd/+junk/rustdate > * Tests. One of the things I like best about Rust is its testing > infrastructure, and one of the things that scares me most about > freebsd-update is its total lack of tests. It has me afraid to > change anything. Rustdate does currently have some tests. Mostly of the easy to test stuff, like parsing the files from the server, and the various internal data manipulation. Testing the unimportant stuff like actually manipulating the system, well, that's harder :) And at least you start out in a less scary place than trying to change the .sh. Things happen in local variables you pass around, rather than global vars and "well-known" temp files that get written in one place and arbitrarily read in another. And being a compiled language gives you a lot of compile-time complaining when you change function args or data structures, instead of weird runtime glitches 8 months later. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From nobody Sat Aug 24 08:44:44 2024 X-Original-To: freebsd-hackers@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 4WrVqq1r0Kz5VQdX for ; Sat, 24 Aug 2024 08:44:55 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Received: from mail-40136.proton.ch (mail-40136.proton.ch [185.70.40.136]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WrVqm5g8Pz4jVT for ; Sat, 24 Aug 2024 08:44:52 +0000 (UTC) (envelope-from developer@lorenzosalvadore.it) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lorenzosalvadore.it header.s=protonmail2 header.b=XQhvDJFj; dmarc=pass (policy=quarantine) header.from=lorenzosalvadore.it; spf=pass (mx1.freebsd.org: domain of developer@lorenzosalvadore.it designates 185.70.40.136 as permitted sender) smtp.mailfrom=developer@lorenzosalvadore.it DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lorenzosalvadore.it; s=protonmail2; t=1724489088; x=1724748288; bh=weiSpL+S6cBPOemP96j994gdkAukMymw0EzGcQNtdMc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XQhvDJFj2k1gqMi5NZBgRMSE5Clra+xI2lxEyLBFvKg4w7PeYGZCko5aX6zMBDjGO 35A3ecem9kVTyc+q9L5cnjtcsjAhVboL/BRl6H1Nq91zW1tNlNgtkhX+4677BPNorw s1dK7xxafAfKTxmgpi+DyBqBZk2r0Mq5A7yTM7eJGM8YKNGnaYoyCaVZuYlZMOaI5m bSGkAU81yLWzkPCOvLPJJAeOEXdABmlPoUWAachV/KHAa9iMiKzLxW0VYA7wGjX+xV HRadb8AeKMaDywvEVWENtJ8K1gkrOAC0B415ShDyxUm/V20FRCyCINfsJl2+81BFHL Ma64ExBU5rF3g== Date: Sat, 24 Aug 2024 08:44:44 +0000 To: "Matthew D. Fuller" From: Lorenzo Salvadore Cc: freebsd-hackers@freebsd.org Subject: Re: Announcing freebsd-rustdate Message-ID: In-Reply-To: References: Feedback-ID: 53711648:user:proton X-Pm-Message-ID: a62162b16ec14c959ca89904b8e4b5f505bea14e List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.17 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.973]; DMARC_POLICY_ALLOW(-0.50)[lorenzosalvadore.it,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; R_DKIM_ALLOW(-0.20)[lorenzosalvadore.it:s=protonmail2]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.70.40.136:from]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[lorenzosalvadore.it:+] X-Rspamd-Queue-Id: 4WrVqm5g8Pz4jVT Hello Matthew, This is very interesting, I believe it deserves an entry in the next status reports. In a few days we will start calling for 2024Q3 reports, but you can send us earlier if you prefer (it is never too early for sending a status report). If you are interested, here are status report submission instructions: https://docs.freebsd.org/en/articles/freebsd-status-report-process/ Cheers, Lorenzo Salvadore On Friday, August 23rd, 2024 at 04:40, Matthew D. Fuller wrote: >=20 >=20 > Do you enjoy using freebsd-update to keep your systems fresh, but not > so much enjoy the vacations you go on while waiting for it finish > doing its thing? Ever wished there was something faster and way less > widely tested you could use instead? Well, today's your lucky day! >=20 > The performance of freebsd-update.sh has bothered me a number of > times, so over the past few months I've been working on a > re-implementation of it in Rust. It's fairly feature complete now, > and seems to be working OK. I've been using it on multiple systems, > and they're all still working. So, it's time for other people to see > it now. >=20 >=20 > I've setup a small site: >=20 > https://rustdate.over-yonder.net/ >=20 > that has a download of a current tarball (a pretty vanilla cargo > workspace), a lot of information on usage, the differences from > freebsd-update.sh, and some deeply unfair speed comparisons. It > awaits your examination, and I await your feedback. >=20 >=20 > Here's some quick summary points; see the site (or the built-in help) > for more details: >=20 > The basic commands (fetch/cron/upgrade/install) are roughly the same. > There's fairly extensive built-in help for the commands and arguments. > A number of parts can make use of multiple cores, so you can get some > nice speedups if you have them. There are progress bars for most > long-running operations. Manual conflict resolution and showing the > details of pending upgrades are separate commands, so 'fetch' and > 'upgrade' don't have any interactive elements. >=20 > Just for a quick taste of the speed difference, with warm caches on my > fairly powerful workstation, upgrading from 13.2-RELEASE to > 14.0-RELEASE-p9 with the full source tree included takes under 2 > minutes with freebsd-rustdate (well under 1 minute, if you disable > fsync), compared to about half an hour for freebsd-update. >=20 >=20 > I'm sure there's lots more testing it needs, so I'd be cautious about > grabbing this and running straight ahead to upgrading your whole > production fleet with it. But I'd love to know about what's missing > or broken, so I can add or fix it. Or about what's working right, so > I can break it. >=20 > It's worked well for me, so it's probably not completely broken. > I've done my best to make it roughly equivalent to the .sh, but > tracking through some the logic in there is kinda twisty. I don't > have any insight into how it's all expected to work except for what I > could glean from those sh-spelunking trips, so I expect there are > still surprises lurking somewhere. >=20 >=20 > In any event, I definitely want to thank Colin Percival and everyone > else who's worked on the existing script and infrastructure over the > years. I'm sure I'm not the only one who appreciates it. And I very > much don't intend anything in this mail or on the site as any sort of > slight against them; shell scripts are just slow. Of course, while > I've done my best to work from the contents of the .sh, all the code > in this is mine, so nothing in it is in any way Colin's fault, or > anyone's but me[0]. >=20 >=20 >=20 > [0] It's probably not my fault either. There's a small family of > elves living in an old ATX case in my closet, who regularly put > bugs into my code. So, really, just blame them. >=20 >=20 >=20 > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ > On the Internet, nobody can hear you scream.