meta-tegra
zfs
meta-tegra | zfs | |
---|---|---|
6 | 752 | |
438 | 10,954 | |
3.0% | 1.8% | |
9.5 | 9.8 | |
2 days ago | 2 days ago | |
BitBake | C | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
meta-tegra
- Switching customers from Linux to BSD because boring is good
-
Cross compile QT6 for Jetson Orin in Linux
If you must compile from source, there is a Yocto layer targeting Orin at https://github.com/OE4T/meta-tegra. Then you can add https://code.qt.io/cgit/yocto/meta-qt6.git/log/ like any yocto layer. The Yocto route is more difficult initially, but it pays off if you need to customize a lot of things.
-
Yocto
This might help you OE4T/meta-tegra
- Linux-factory: A framework used to create custom Linux Debian operating systems
-
Solving Entry-Level Edge AI Challenges with Nvidia Jetson Orin Nano
Related, so I'd like to give a shout out to the guys who made meta-tegra[1] possible so that I don't have to use NVidia's garbage software, which barely resembles something you get out of a proper SBC.
[1] https://github.com/OE4T/meta-tegra
-
Is there a way to cleanly install Ubuntu 20 on the NX?
If you need newer versions of certain libraries / other software, you can have a look at OE4T and use it to build your own system images. This will not remove all restrictions ( you will still be unable to update the kernel, of course ) but you can more easily use more current software versions for parts of the system that have no direct NVIDIA dependency.
zfs
-
Ask HN: Who is hiring? (February 2025)
We develop new features, investigate/fix bugs, and support the community of these important open source infrastructure projects. Some of our recent work includes major ZFS features such as Linux Containers support (OpenZFS 2.2: https://github.com/openzfs/zfs/pull/12263), and Fast Deduplication (OpenZFS 2.3: https://github.com/openzfs/zfs/discussions/15896).
We successfully hired from HN in the last round and are looking for more OpenZFS Developers (3+ years of experience) to join our team!
- Strong skills with Kernel C programming and data structures
-
Working with Files Is Hard
There are actually several distinct issues being reported there. I replied responding to everyone who posted backtraces and a few who did not:
https://github.com/openzfs/zfs/issues/9130#issuecomment-2614...
That said, there are many others who stress ZFS on a regular basis and ZFS handles the stress fine. I do not doubt that there are bugs in the code, but I feel like there are other things at play in that report. Messages saying that the txg_sync thread has hung for 120 seconds typically indicates that disk IO is running slowly due to reasons external to ZFS (and sometimes, reasons internal to ZFS, such as data deduplication).
I will try to help everyone in that issue. Thanks for bringing that to my attention. I have been less active over the past few years, so I was not aware of that mega issue.
-
GitHub Linux ARM64 hosted runners now available for free in public repositories
This is excellent news, as it should unblock having precompiled packages available for a number of applications for arm64—for me, most notably, OpenZFS: https://github.com/openzfs/zfs/issues/14511
-
ZFS 2.3.0 released with ZFS raidz expansion
Heavy synchronous IO from incredibly frequent fsync is a weak point. You can make it better using SLOG devices. I realize what I am about to say is not what you want to hear, but any application doing excessive fsync operations is probably doing things wrong, and this is a view that you will find prevalent among all filesystem developers (e.g. the ext4 and XFS guys will have this view too).
In the case of APT, it should install all of the files and then call sync() once. This is equivalent of calling fsync on every file like APT currently does, but aggregates it for efficiency. The reason APT does not use sync() is probably a portability thing, because the standard does not require sync() to be blocking, but on Linux it is:
https://www.man7.org/linux/man-pages/man2/sync.2.html
That said, slow fsync performance generally is not an issue for desktop workloads because they rarely ever use fsync. APT is the main exception. You are the first to complain about APT performance in years as far as I know (there were fixes to improve APT performance 10 years ago, when its performance was truly horrendous).
You can file bug reports against ZFS here:
https://github.com/openzfs/zfs
I suggest filing a bug report against APT. There is no reason for it to be doing fsync calls on every file it installs in the filesystem. It is inefficient.
-
Nix – Death by a Thousand Cuts
I'm subscribed to this GitHub issue to follow the situation:
https://github.com/openzfs/zfs/issues/12014
It might not be the only issue related to ZFS native encryption but, at the very least, as long as this one isn't closed I'm assuming it's still not safe.
-
We fine-tuned Llama and got 4.2x Sonnet 3.5 accuracy for code generation
I would be interested in a fine tune on OpenZFS:
https://github.com/openzfs/zfs
-
Static search trees: 40x faster than binary search
Your article led me to wonder if our b-trees would be faster if I switched the intra node operations to use Eytzinger ordered arrays:
https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...
There are two ways to look at this Big O wise. One is that insertions and deletions would be asymptomatically faster since memmove() is a linear operation. Look ups would not be any different asymptotically, but the constant factor might improve from being able to do prefetch. The other way is that the N is bounded, such that it is all O(1) and the difference is how big O(1) is.
I imagine I could implement it and benchmark it. However, my intuition is that the end result have lookups be marginally faster to the point of splitting hairs while insertions and deletions would be slower. While memmove() is a technically a linear time operation, it is a sequential operation that has a very low constant factor. The bubble up and bubble down operations needed to do insertions and deletions in a Eytzinger ordered array are technically random access, which has a higher constant factor. At some point, the Eytzinger ordered array operations should win, but that point is likely well beyond the size of a b-tree node.
My reason for saying this is to say that Big O notation still matters, but understanding when the constant factor is significant is important.
- ZFS checksum flaw: Corruption may be left unnoticed
-
Bill requiring US agencies to share source code with each other becomes law
It happens. The following repository was originally used only by LLNL before it gained contributors and then was promoted to the OpenZFS repository:
https://github.com/openzfs/zfs
If you are not doing multithreading, this sound static analyzer should be fairly useful:
https://github.com/NASA-SW-VnV/ikos
Unlike others, it attempts to prove code safety. Unfortunately, it does not currently handle multi-threading and a few other cases.
-
We use our own hardware at Fastmail
Thank you for posting the comment. The process of writing my reply gave me a flash of inspiration:
https://github.com/openzfs/zfs/pull/16896
I doubt that this will make us as fast as ext4 is at unlinking files in a single thread, but it should narrow the gap. It also should make many other common operations somewhat faster. There might also be opportunities for further improvements depending on what profiling reveals.
What are some alternatives?
Fedora-Virt-Lab - A demo for setting up a Fedora hypervisor for your home lab using Ansible, Web Console, and Image Builder
7-Zip-zstd - 7-Zip with support for Brotli, Fast-LZMA2, Lizard, LZ4, LZ5 and Zstandard
linux-factory - a framework used to create custom debian linux operating systems
zstd - Zstandard - Fast real-time compression algorithm
SkiffOS - Any Linux distribution, anywhere.
zfsbootmenu - ZFS Bootloader for root-on-ZFS systems with support for snapshots and native full disk encryption
buildroot - Buildroot, making embedded Linux easy. Note that this is not the official repository, but only a mirror. The official Git repository is at https://gitlab.com/buildroot.org/buildroot/. Do not open issues or file pull requests here.
snapper - Manage filesystem snapshots and allow undo of system modifications
unix-history-repo - Continuous Unix commit history from 1970 until today
sanoid - These are policy-driven snapshot management and replication tools which use OpenZFS for underlying next-gen storage. (Btrfs support plans are shelved unless and until btrfs becomes reliable.)
RocksDB - A library that provides an embeddable, persistent key-value store for fast storage.
zrepl - One-stop ZFS backup & replication solution