Summary
This article records my experience of contributing to an open source project Iggy under The Apache Software Foundation , while also sharing some of my personal insights.

About Apache
The Apache Software Foundation, a U.S. 501(c)(3) non-profit foundation committed to software for the public good with the “Community over Code” ethos, manages hundreds¹ of influential open source projects that underpin core infrastructure in cloud, big data and web industries, based on community and sponsors, boasting an ecosystem valued at over $30 Billion USD .²

About Iggy
Apache Iggy, an incubating open source message streaming project at The ASF, is a Rust built, ultra low latency persistent platform that processes millions of messages per second to power high efficiency rt data pipelines and cloud native streaming workloads at laser speed.

When Editing
The syntax has been corrected by LLM. Article done after committing some codes.

How I Discovered#

The ASF#

In 2021, I learned about Log4j³ (CVE-2021-44228)⁴CVSSv3 10.0/10.0 vulnerability⁵.
I’m sorry to have gotten to know you this way.

The Apache Iggy#

This brings me to the situation I had in early November 2025.

First, while I already knew how to use proxies in the 5th grade, and “could write”⁶Java code in the 6th grade, I made virtually not so many contributions to the open source community from 2021 to 2024. The reason is quite straightforward, I was obsessed with Minecraft during the 2021 academic year, immersed in Genshin Impact (Asia Server) in 2022, and took up Arknights in 2023. These three distractions completely squandered most of my time that could have been spent tinkering with distros and coding langs⁷.

Despite my early start in tech, I lack extensive experience in multiple areas, not just development experience, but also collaboration experience. This deficiency is already evident in my use⁸ of Git, and more shortcomings will quickly surface once I engage in actual development. These shortcomings are not merely limited to not knowing how to use Docker or distributed compilers , but extend to basic coding standards. Thus, my needs became clear from now on:

A small or mid scale open source project, better led by an organization or enterprise, to correct my various bad habits;
A project in its early/mid-stage of development with active maintainers, Learn effective communication;
The project itself should have a steady pace of progress;
The project language I prefer to use.

This led me to Apache. After reading their charter and mission, finding their GitHub account, and conducting searches, I discovered that Apache Iggy was the only project that fully met all the above requirements.

apache

iggy

Waiting for api.github.com...

00K

Waiting...

Ask for Assignment#

Pick Up One Issue#

The Apache Software Foundation encourages people to contribute. Volunteers who are unsure where to start can take a look at the project’s good first issues. That’s how I began too: I picked the oldest unclaimed issue. The reason was simple. As a Chinese high school student, I had less than 20 hours available per weekend, and my skills were rusty, so I was worried the work would drag on for a long time.

Contributor Ladder
First, you are a contributor, then you are a committer, and finally you are a PMC member or higher. You may notice that there are also PPMC, which is member of Podling Project Management Committee , belongs to Apache Incubator.

GitHub is Not Necessary
Apache projects are NOT necessarily hosted on GitHub. Many long established Apache projects still use Apache SVN as their primary version control system and Bugzilla for issue tracking, like Apache HTTP Server Project, rather than GitHub’s Issues and Pull Requests mechanism.

Ask the Collaborators#

I figured an issue that had been around for a long time probably meant it was important but not urgent for the maintainers, which would alleviate the mess on them from my slow progress.

Piotr Gankiewicz

@spetz. Software Engineer, Iggy Founder, Apache PPMC.

Hubert Gruszecki

@hubcio. Another crab enthusiast, Apache PPMC.

By checking who merged the pull requests, we could easily tell who has write access. I made an attempt sending a request to @hubcio . He agreed promptly. Later, @spetz also joined the code review. @hubcio and @spetz are highly efficient and responsible collaborators. They’re both Members, and PPMCs.

Communication Methods
Email communication is also recommended at times, which might be PUBLIC. You can receive real-time messages from mailing lists by sending a subscription confirmation. For instance:

Get On Work#

Preparation#

Iggy can be deployed with Docker easily:

1
docker pull apache/iggy:latest
2
docker run --cap-add=SYS_NICE --security-opt seccomp:unconfined --ulimit memlock=-1:-1 apache/iggy:latest

Just like when making contributions normally, first read through the Code of Conduct, Contributing Guidelines, and then make a fork, syncing. Besides, Iggy also provides a cli.


2 collapsed lines
1
git clone git@github.com:Svecco/iggy.git
2
cd ./iggy/ && ssh-add ~/.ssh/id_ed25519
3
git checkout -b 46-size-logs upstream/master
4
cargo install iggy-cli && iggy --help

Nearly all medium or large modern Rust projects adopt the workspace mechanism. I’m not sure why so many Rust learning materials don’t cover it as a key topic, including the Programming Rust, 2nd Edition I have right now.


4 collapsed lines
1
╭─ $ [svecco] ~/A/iggy git!(46-size-logs)
2
╰─ > cargo clean
3
     Removed 65558 files, 52.1GiB total
4
╭─ $ [svecco] ~/A/iggy git!(46-size-logs)
5
╰─ > time sh -c 'cargo build --all-features --all-targets --workspace --release 2>&1 | tail -1'
6
    Finished `release` profile [optimized] target(s) in 3m 18s
2 collapsed lines
7

8
________________________________________________________
9
Executed in  198.65 secs    fish           external
10
   usr time   51.93 mins  407.00 micros   51.93 mins
11
   sys time    1.46 mins   61.00 micros    1.46 mins
5 collapsed lines
12
╭─ $ [svecco] ~/A/iggy git!(46-size-logs)
13
╰─ > lscpu | grep "AMD"
14
Vendor ID:                               AuthenticAMD
15
Model name:                              ***AMD Ryzen 9 9950X*** 16-Core Processor
16
Virtualization:                          AMD-V

From the project specifications, you can also see how to format your code:

About Clippy and Check
Clippy is a superset of check. Usually, if Clippy passes, you don’t need to run check.

1
cargo fmt --all && cargo sort --workspace && cargo machete
2
cargo clippy --all-targets --all-features -- -D warnings
3
bash ./scripts/ci/licenses-list.sh --update --fix
4
bash ./scripts/ci/trailing-whitespace.sh --check --fix
5
# cargo check --all-targets --all-features

1
cargo run --bin iggy-bench -- -T 50000MB pp -p 5 quic

1
set -x IGGY_ROOT_USERNAME iggy && set -x IGGY_ROOT_PASSWORD iggy && set -x RUST_LOG debug && cargo run --bin iggy-server -- --with-default-root-credentials
2
set -x PUBLIC_IGGY_API_URL http://127.0.0.1:3000 && cd web/ && pnpm run dev #If env wasn't set before, please run pnpm/npm (or sth else) install

Learn the Structure#

Iggy data model, aligned with mainstream message queue, but has own naming convention.⁹

Concept	Core Description
`Stream`	Top-level namespace isolating business/project message data.
`Topic`	Message classification under Stream; maps to message queue; one Stream has many Topics.
`Partition`	Parallel unit under Topic; determines concurrency; one Topic has many Partitions.
`Message`	Smallest data carrier; contains payload, ID, timestamp, offset, custom headers.
`Consumer`	Message consumption endpoint; supports pull by offset, timestamp, batch; auto-commits offsets.

Iggy’s core business data model and interaction logic. It defines the nested hierarchy from the top-level namespace Stream down to the atomic data unit Message, and standardizes the core send/poll operations between producers and consumers.

\mathbf{BA} \equiv \begin{cases} \mathbf{Hierarchy}: & \mathbf{Stream} \supset \mathbf{Topic} \supset \mathbf{Partition}_i \supset \mathbf{Message}_{i,j} \\ & (i,j \in \mathbb{N}^+) \\[0.4em] \mathbf{Flow}: & \mathbf{Producer} \xrightarrow{\text{Send}(s,t,p,m)} \mathbf{Partition}_p \\ & \mathbf{Consumer}_c \xrightarrow{\text{Poll}(s,t,p,o,k)} \left\{ \mathbf{Message}_{p,o}, \dots \right\} \end{cases}

Iggy’s layered technical architecture. It maps the complete end-to-end data path from multi-language SDK clients through the transport layer and core processing engine to the persistent storage layer, along with the officially supported transport protocol options.

\mathbf{TA} \equiv \begin{cases} \mathbf{Layers}: & \mathbf{Client_{SDK}} \xrightarrow{\mathcal{R}} \mathbf{Transport_{[4\text{-}prot]}} \\ & \mathbf{Transport} \xrightarrow{\mathcal{D}} \mathbf{Core_{[Mgmt|HB|Router]}} \\ & \mathbf{Core} \xrightarrow{\mathcal{P}} \mathbf{Storage_{[Seg|Idx|Meta]}} \\[0.4em] \mathbf{Constraints}: & \mathcal{C}(\mathbf{Transport}) \equiv \left( \mathbf{TCP} \lor \mathbf{HTTP} \lor \mathbf{QUIC} \lor \mathbf{WS} \right) \end{cases}

Iggy’s two core end-to-end workflows: message production and consumption. It details the full lifecycle of a message, covering client authentication, routing and persistent append for production, as well as subscription, batch fetching and offset commit for consumption.

\mathbf{Workflow} \equiv \mathbf{WF_{Prod}} \land \mathbf{WF_{Cons}} \\[0.6em] \mathbf{Workflow_{Prod}} \equiv \mathbf{Producer} \xrightarrow{\text{Connect}} \mathbf{Transport} \xrightarrow{\text{Auth}(u,p)} \mathbf{Core} \\ \quad \xrightarrow{\text{Route}(s,t,p)} \mathbf{Partition} \xrightarrow{\text{Append}(m)} \mathbf{Storage_{Seg}} \\[0.6em] \mathbf{Workflow_{Cons}} \equiv \mathbf{Consumer} \xrightarrow{\text{Subscribe}(s,t)} \mathbf{Core} \xrightarrow{\text{Poll}(p,o,k)} \mathbf{Storage_{Seg}} \\ \quad \xrightarrow{\text{Read}(o,k)} \left\{ m_1, \dots, m_k \right\} \xrightarrow{\text{Commit}(o+k)} \mathbf{Core}

Path	Work
core/server/src/configs	Config management
core/server/src/log	Logging management

And for the issue, for example, server.toml controls the default configuration file, while defaults.rs handles the parsing of default values, and validators.rs is responsible for validating data integrity preventing issues like rotation times approaching zero¹⁰, for instance.

In the integration phase, as the name, we perform integration testing, which fully and independently implements features testing. Relying solely on unit testing is insufficient for complex projects involving overall system operation.

Implementing Feats#

1
fn calculate_max_files(max_total_size, max_file_size,) -> usize { ... }
2
fn install_log_rotation_handler(&self, config, logs_path,) -> Option<()> { ... }
3
fn run_log_rotation_loop(path, retention, ... , check_interval, should_stop, rx,) { ... }
4
fn read_log_files(logs_path) -> Vec<(fs::DirEntry, SystemTime, Duration, u64)> { ... }
5
fn cleanup_log_files(logs_path, retention, max_total_size, max_file_size,) { ... }
6
impl Drop for Logging { fn drop(&mut self) { ... } }

Logically, the implementation is straightforward, divide max_total_size by max_file_size to get the upper limit of the quantity, then read the rotation_check_interval and retention cycles configured by the user. After that, push file entries to Vec<(fs::DirEntry, SystemTime, Duration, u64)>, after calculating, for deletion according to these scheduled timings, and finally remove a batch.

1
fn is_valid_iggy_log_file(file_name,) -> bool { ... }
2
async fn run(client_factory, log_dir, present_log_config,) { ... }
3
async fn init_valid_client(client_factory,) -> Result<IggyClient, String> { ... }
4
async fn generate_enough_logs(client,) -> Result<(), String> { ... }
5
async fn validate_log_rotation_rules(log_dir, pre_config,) -> Result<(), String> { ... }
6
async fn nocapture_observer(log_path, title, done,) -> () { ... }

1
# Maximum size of a single log file before rotation occurs. When a log
4 collapsed lines
2
# file reaches this size,  it will be rotated   (closed and a new file
3
# created). This setting works together with max_total_size to control
4
# log storage.  You can set it to 0 to enable unlimited size of single
5
# log,  but all logs will be written to a single file,  thus disabling
6
# log rotation. Please configure 0 with caution, esp. RUST_LOG > debug
7
max_file_size = "500 MB"
8

9
# Maximum size of the log files before rotation.
10
max_size = "512 MB"
5 collapsed lines
11

12
# Maximum total size of all log files.  When this size is reached,
13
# the oldest log files will be deleted first. Set it to 0 to allow
14
# an unlimited number of archived logs. This does not disable time
15
# based log rotation or per-log-file size limits.
16
max_total_size = "4 GB"
3 collapsed lines
17

18

19
# Time interval for checking log rotation status. Avoid less than 1s.
20
rotation_check_interval = "1 h"
3 collapsed lines
21

22

23
# Time to retain log files before deletion. Avoid less than 1s, too.
24
retention = "7 days"

The above are configuration level changes, and you can also see what has been implemented from here. Of course, for more specific details, you may as well directly use the commit hash to check the git log to find out about other additions and deletions. Since the issues people encounter are diverse, and log rotation is not highly technical, going into detail here would sacrifice general applicability. So, I won’t elaborate on the general implementation details here, instead, I will choose to pick things that I find quite interesting up later.

1
git show 873b63965998e07ed7b50994286d1397b6359dd5 --stat

1
╭─ $ [svecco] ~/A/iggy git!(master)
2
╰─ > git show 873b63965998e07ed7b50994286d1397b6359dd5 --stat
28 collapsed lines
3
commit 873b63965998e07ed7b50994286d1397b6359dd5
4
Author: Svecco <chenrui@sve.moe>
5
Date:   Mon Feb 2 17:43:48 2026 +0800
6

7
    feat(server): implement log rotation based on size and retention (#2452)
8

9
    - implemented log rotation based on size and retention as the title;
10
    - implemented configurable attributes and imported breaking changes;
11
    - added units and integration test in logger.rs and integration mod;
12
    - added documentations and imported new dependencies, etc.
13

14
 Cargo.lock                                           |  21 +
15
 DEPENDENCIES.md                                      |   2 +
16
 core/common/src/utils/byte_size.rs                   |   7 +
17
 core/common/src/utils/duration.rs                    |  29 ++
18
 core/integration/src/test_server.rs                  |   4 +-
19

20
 core/integration/tests/S/S/log_rotation_scenario.rs  | 382 +++++++++++++++++
21
 core/integration/tests/server/scenarios/mod.rs       |   1 +
22
 core/integration/tests/server/specific.rs            |   5 +-
23
 core/server/Cargo.toml                               |   2 +
24
 core/server/config.toml                              |  22 +-
25
 core/server/src/configs/defaults.rs                  |   9 +-
26
 core/server/src/configs/displays.rs                  |   8 +-
27
 core/server/src/configs/system.rs                    |   7 +-
28
 core/server/src/configs/validators.rs                |  47 ++-
29
 core/server/src/log/logger.rs                        | 475 +++++++++++++++++++++-
30
 foreign/cpp/tests/e2e/server.toml                    |  26 +-
31
 16 files changed, 1009 insertions(+), 38 deletions(-)

Panicked OOM Code 12 with 44GiB RAM Empty?!#

1
git reset --hard ff6695ba589656acef68da534b4af55dda452c80 && cargo build --package server
2
CPU_ALLOCATION="<more than your PHYSICAL cores>" RUST_BACKTRACE=1 cargo run --bin server

Couldn’t Load Data From Disk?
That’s because the process attempted to read an incompatible system metadata file under the ./local_data/ directory. Just remove the ./local_data/ directory and try again.

Regarding the Num of Cores
On my device, testing shows that cpu_allocation = "19" is the limit, with single one 32 logical cores, distributed off. Might require a machine with ~~many cores~~ no, but SMT to trigger.¹¹

Generally speaking, this situation occurs because the requested memory allocation is too large. The malloc function is overwhelmed and just kills the process (tears included). But you can check out, and, find there may something incorrect, but you don’t know exactly what it is:

1
unlimited, unlimited, 0

That’s very strange for me. There are no external restrictions, on the contrary, resources are sufficient, yet it still fails to start, So this is an internal server issue?

1
2026-02-13T10:08:28.268923Z ERROR     main iggy_server: Server shutting down due to shard failure. (shutdown took 31 ms)
2
Error: ShardFailure { message: "Shard 22 panicked: called `Result::unwrap()` on an `Err` value: Os { code: 12, kind: OutOfMemory, message: \"Cannot allocate memory\" }" }

1
          total        used        free      shared  buff/cache   available
2
Mem:      46 Gi       20 Gi      772 Mi      199 Mi       24 Gi       26 Gi

Since the error is occurring with the shard, let’s look into the code that implements the shard functionality. Let’s check how the shard allocated.

1
impl CpuAllocation {
2
    pub fn to_shard_set(&self) -> HashSet<usize> {
3
        match self {
4
            CpuAllocation::All => {
5
                let available_cpus = available_parallelism()
6
                    .expect("Failed to get num of cores")
7
                    .get();
8

9
                (0..available_cpus).collect()
10
            }
11
            CpuAllocation::Count(count) => (0..*count).collect(),
12
            CpuAllocation::Range(start, end) => (*start..*end).collect(),
13
        }
14
    }
15
}

This code that executes kernel allocation seems harmless enough at first glance, yet there appears to be something off about it. The cores are allocated via available_parallelism(), man it, see what can we get from the documentations.

Limitations¹² / pub fn available_parallelism() -> Result<NonZero<usize>>#
The purpose of this API is to provide an easy and portable way toquery the default amount of parallelism the program should use.Among other things it does not expose information on NUMA regions,does not account for differences in (co)processor capabilities orcurrent system load, and will not modify the program’s global statein order to more accurately query the amount of available parallelism.

“NUMA regions”? What is “NUMA”?

In early computer systems, all CPU accessed memory through a single bus, an architecture known as SMP¹³. All CPU were equal, with no master slave relationship. As the number of processors increased, the system bus became a critical system bottleneck, leading to significant latency in communication between processors and memory.

From the Hardware Architecture
In the NUMA architecture, CPU are divided into multiple NUMA Nodes. Each node has its own independent memory space and PCIe bus subsystem. Intercommunication between CPU is achieved via the QPI bus.¹⁴

The speed at which a CPU accesses memory from different node types varies: access to the local node is the fastest, while access to remote nodes is the slowest. In other words, memory access speed depends on the distance to the node, the greater the distance, the slower the access. This is why it is called NUMA. The memory access distance is referred to as Node Distance.

This architecture effectively solves the performance issues caused by large scale CPU expansion under the SMP model.¹⁵ This means: This piece of code directly maps abstract CPU allocation rules to a set of logical CPU core IDs, where cpu_allocation = "all" generates a set with a size equal to the number of logical cores reported by the system. In this scenario, 32 shards are created instead of 16, which triggers two cascading issues: first, multiple shards are bound to the SMT threads of the same physical core, resulting in resource contention. Second, the 32 shards, combined with the pre-allocated memory pool, generate a massive amount of instantaneous memory requests. This value exceeds the kernel’s heuristic memory overcommit threshold vm.overcommit_memory=0, thereby triggering Code 12 and causing shard crashes.¹⁶

Now, we can examine the source code to see why the documentation states this.

1
pub fn available_parallelism() -> io::Result<NonZero<usize>> {
4 collapsed lines
2
    cfg_select! {
3
        any(target_os = "linux") => {
4
            #[cfg(any(target_os = "android", target_os = "linux"))]
5
            {
6
                quota = cgroups::quota().max(1);
7

8
                let mut set: libc::cpu_set_t = unsafe { mem::zeroed() };
9
                unsafe {
11 collapsed lines
10
                    if libc::sched_getaffinity(0, size_of::<libc::cpu_set_t>(), &mut set) == 0 {
11

12
                        let count = libc::CPU_COUNT(&set) as usize;
13
                        let count = count.min(quota);
14

15
                        if let Some(count) = NonZero::new(count) {
16
                            return Ok(count)
17
                        }
18
                    }
19
                }
20
            }
21

22
            match unsafe { libc::sysconf(libc::_SC_NPROCESSORS_ONLN) } {
4 collapsed lines
23
                -1 => Err(io::Error::last_os_error()),
24
                0 => Err(io::Error::UNKNOWN_THREAD_COUNT),
25
                cpus => {
26
                    let count = cpus as usize;
27
                    let count = count.min(quota);
28

29
                    Ok(unsafe { NonZero::new_unchecked(count) })
4 collapsed lines
30
                }
31
            }
32
        }
33
    }
34
}

Over? Nope, still a little. I found this option in the configuration:

1
# Size of the memory pool (string).
2
# Example: "512 MiB" or "1 GiB".
3
# This defines the maximum, total memory allocated for the memory pool.
4
# Note: This number has to be multiplication of 4096 (default linux page size).
5
# Minimum size is 512 MiB due to internal implementation details.
6

7
size = "4 GiB"

Reducing the memory pool size (e.g., from 4 GiB to 1 GiB) lowers the initial pre-allocation peak and decreases the total instantaneous memory demand. This value may fall within the kernel’s “repayable” memory range, allowing the server to start occasionally.

However, this only alleviates the symptoms and does not address the root cause. Physical cores and SMT threads are not distinguished, nor is there a limit on the maximum number of shard. Ultimately, this amplifies memory pressure to the point of triggering an OOM error on SMT enabled multi cores CPU.

When the First Time I Encountered This
Of course, I didn’t know any of this at the beginning of the pull request, nor did I realize it was a NUMA issue. I was fixated entirely on the memory side and was just about to file an issue. After fetching, the problem was suddenly resolved. With some locates, let’s take a look at the commit that fixed the issue.
addressing #2387, feat(server): NUMA awareness (#2412), committed by @tungtose
1
git show a5d569450ee34441be997786046c7a30785e11f2 --stat

Links to the Original Issue and Pull Request
The issue was handled by @tungtose , and the image above was the flow he drew. You can find the original issue #2387 here, filed by @hubcio (Hubert Gruszecki) , and the original pull request here #2412. Merged by @spetz (Piotr Gankiewicz) on Dec 15, 2025.

1
# line 135
2
hwlocality = "1.0.0-alpha.11"

1
// line 50
2
#[derive(Debug, Clone, PartialEq, Default)]
3
pub struct NumaConfig {
3 collapsed lines
4
    pub nodes: Vec<usize>,
5
    pub cores_per_node: usize,
6
    pub avoid_hyperthread: bool,
7
}
8

9
// line 178
10
#[derive(Debug)]
11
pub struct NumaTopology {
4 collapsed lines
12
    topology: Topology,
13
    node_count: usize,
14
    physical_cores_per_node: Vec<usize>,
15
    logical_cores_per_node: Vec<usize>,
16
}

1
impl ShardInfo {
2
    pub fn bind_memory(&self) -> Result<(), ServerError> {
3

4
        if let Some(node_id) = self.numa_node {
5
            let topology = Topology::new().map_err(|err| ServerError::TopologyDetection {
3 collapsed lines
6
                msg: err.to_string(),
7
            })?;
8

9

10
            let node = topology
11
                .objects_with_type(ObjectType::NUMANode)
12
                .nth(node_id)
5 collapsed lines
13
                .ok_or(ServerError::InvalidNode {
14
                    requested: node_id,
15
                    available: topology.objects_with_type(ObjectType::NUMANode).count(),
16
                })?;
17

18
            if let Some(nodeset) = node.nodeset() {
19

20
                topology
21
                    .bind_memory(
15 collapsed lines
22
                        nodeset,
23
                        MemoryBindingPolicy::Bind,
24
                        MemoryBindingFlags::THREAD | MemoryBindingFlags::STRICT,
25
                    )
26
                    .map_err(|err| {
27
                        tracing::error!("Failed to bind memory {:?}", err);
28
                        ServerError::BindingFailed
29
                    })?;
30

31
                info!("Memory bound to NUMA node {node_id}");
32
            }
33
        }
34

35
        Ok(())
36
    }
37
}

Although I don’t understand it many¹⁷, it’s much better than the indiscriminate thread allocation based on simple CPU sets from available_parallelism(). And even more delightful is that as a newcomer, ~~I can finally write code happily~~.

Tungtose

@tungtose. No description provided.

Wait, Some Compiling Dependencies Missing#

It turns out that hwloc-devel was missing, maybe can infer that the bug has truly been fixed XD.

But something still doesn’t seem right?


4 collapsed lines
1
thread 'main' (948800) panicked at /home/svecco/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-4dc01642fd091eda/hwlocality-sys-0.6.4/build.rs:82:10:
2
Could not find a suitable version of hwloc:
3
pkg-config exited with status code 1
4
> PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --static --libs --cflags hwloc 'hwloc >= 2.0.0' 'hwloc < 3.0.0'
5

6
The system library `hwloc` required by crate `hwlocality-sys` was not found.
7
The file `hwloc.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
5 collapsed lines
8
The PKG_CONFIG_PATH environment variable is not set.
9

10
HINT: if you have installed the library, try setting PKG_CONFIG_PATH to the directory containing `hwloc.pc`.
11

12
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Of course, we can instantly solve this problem by installing hwloc-devel package via dnf:


3 collapsed lines
1
Updating and loading repositories:
2
Repositories loaded.
3
Package                  Arch    Version                  Repository         Size
4
Installing:
5
 hwloc-devel             x86_64  2.12.0-2.fc43            fedora        665.3 KiB
22 collapsed lines
6
Installing dependencies:
7
 infiniband-diags        x86_64  58.0-4.fc43              fedora        961.8 KiB
8
 libibumad               x86_64  58.0-4.fc43              fedora         43.9 KiB
9
 rdma-core-devel         x86_64  58.0-4.fc43              fedora        613.8 KiB
10

11
Transaction Summary:
12
 Installing:         4 packages
13

14
Total size of inbound packages is 1 MiB. Need to download 1 MiB.
15
After this operation, 2 MiB extra will be used (install 2 MiB, remove 0 B).
16
Is this ok [y/N]: y
17
[1/4] infiniband-diags-0:58.0-4.fc43.x86 100% | 611.2 KiB/s | 328.2 KiB |  00m01s
18
[2/4] hwloc-devel-0:2.12.0-2.fc43.x86_64 100% | 664.9 KiB/s | 361.0 KiB |  00m01s
19
[3/4] rdma-core-devel-0:58.0-4.fc43.x86_ 100% | 712.8 KiB/s | 429.8 KiB |  00m01s
20
[4/4] libibumad-0:58.0-4.fc43.x86_64     100% | 372.5 KiB/s |  27.2 KiB |  00m00s
21
---------------------------------------------------------------------------------
22
[4/4] Total                              100% |   1.8 MiB/s |   1.1 MiB |  00m01s
23
Running transaction
24
[1/6] Verify package files               100% |   1.3 KiB/s |   4.0   B |  00m00s
25
[2/6] Prepare transaction                100% |  19.0   B/s |   4.0   B |  00m00s
26
[3/6] Installing libibumad-0:58.0-4.fc43 100% |   2.3 MiB/s |  44.7 KiB |  00m00s
27
[4/6] Installing infiniband-diags-0:58.0 100% |  56.2 MiB/s | 978.7 KiB |  00m00s
28
[5/6] Installing rdma-core-devel-0:58.0- 100% |  41.7 MiB/s | 682.7 KiB |  00m00s
29
[6/6] Installing hwloc-devel-0:2.12.0-2. 100% |   2.7 MiB/s | 747.8 KiB |  00m00s
30
Complete!

But why does the installation of hwloc still fail when using Nix? Go have some tries.

1
nixos-version:                  25.11.20251215.c6f52eb (Xantusia)
2
hwloc-info --version:           hwloc-info 2.12.2rc1-git

1
.r--r--r-- 439 root  1 Jan  1970 hwloc.pc

Hmm… that’s really puzzling. But there’s a somewhat hacky way to fix it.

1
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.33s

Let’s look at the source code. Ah, if hwloc.pc is in the dev of the nixpkgs, there will be multiple outputs… So I can’t rely on installing it correctly by just adding the package name directly.

1
outputs = [ "out" "lib" "dev" "doc" "man" ];
2
# "out" was the default output. Below was my installation:
3
packages = with pkgs; [ hwloc ];

IEC != SI#

The picture below shows the textbook for Information Technology in Chinese senior high.

But IT IS WRONG¹⁸. The correct one is following IEC 60027-2¹⁹, which looks like this²⁰.

Units Computers Use	IEC	Value	Units Hardware Vendors Use	SI	Value
Kibibyte	KiB	1024¹	Kilobyte	kB	1000¹
Mebibyte	MiB	1024²	Megabyte	MB	1000²
Gibibyte	GiB	1024³	Gigabyte	GB	1000³
Tebibyte	TiB	1024⁴	Terabyte	TB	1000⁴
Pebibyte	PiB	1024⁵	Petabyte	PB	1000⁵
Exbibyte	EiB	1024⁶	Exabyte	EB	1000⁶
Zebibyte	ZiB	1024⁷	Zettabyte	ZB	1000⁷
Yobibyte	YiB	1024⁸	Yottabyte	YB	1000⁸

I didn’t know any of this at first, until started with the Apache Iggy, @Hubcio pointed it out to me.

1
 assert_eq!( return_bytes(1 GiB) ,        1000000000 );
2
/* Panicked. Left: 1073741824    , Right: 1000000000 */

Are You Sure#

Alright, I’m not sure really. I’ll take a closer look before --force it next time. If I don’t have enough time, just test it later, also learn to write your own test scenarios. Don’t always ask others to test features, it’s not a good practice, and usually wastes maintainers’ time.

Now, let’s see what silly things this guy @Svecco did.

1
if let Err(e) = std::fs::create_dir_all(&logs_path) {
2
    tracing::warn!("Failed to create logs directory {:?}: {}", logs_path, e);

1
// Check available disk space, at least 10MiB
2
let min_disk_space: u64 = 10 * 1024 * 1024;

1
let max_files = Self::calculate_max_files(
2
    config.max_size.as_bytes_u64(),
3
    config.max_size.as_bytes_u64(),

1
let path = logs_path.to_path_buf();
2
let max_size = config.max_size.as_bytes_u64();
3
let retention = config.retention.get_duration();
4
let rotation_mutex = Arc::new(Mutex::new(()));

1
fn default_max_total_log_size() -> IggyByteSize { IggyByteSize::from(4_000_000_000) }
2
fn default_log_rotation_check_interval() -> u64 { 3600 }

1
fn install_log_rotation_handler(&self, config: &LoggingConfig, logs_path: Option<&PathBuf>) { ... }

1
fn cleanup_log_files(logs_path: &PathBuf, retention: Duration, max_size_bytes: u64) {...}

1
match rotation_result {
2
    Ok(()) => println!("Succeeded Verified Log Rotation"),
3
    Err(e) => { eprintln!("Failed: {e}"); }
4
}

I don’t know if staying up late frequently is one of the reasons for these outrageous problems.
But for now, it just seems like an excuse for not being good enough.

Btw, according to Programming Rust , when there are multiple line macro calls, rem comma. ²¹

1
reg_set_bits!(
2
    GPIO_CTRL_REG, /*
3
    0x01,           *   Typically, it refers to multi lines
4
    0x04,           *   macro invocations with a variable
5
    0x10            *   number of arguments.
6
    0x10,           *   Go Add Trailing Comma.
7
)?;                 */

Make a Clean Git Log#

Judging from the current git log of the sve.moe site’s refactoring:

1
5f5d99c arst   | 4b5b2a9 fix(style): err rendered btn and refine horizonal lines
2
e46e4af qwfp   | 211112c fix(name): officiallly, NixOS CN Meetup -> NixCN Conference
3
221db94 neio   | 42d9a53 fix(render): remove duplicate blur to reduce graphics load (#12)
4
eb408c2 ??     | 83d643e fix(archives): which to keep, which ... carry on. (#11)
5
b81821e xcdv   | 34ca32e feat(sve): some() => render.presure().alleviate(bit) (#10)
6
4db971b ababa  | 65f1d68 feat(api): impl data cache for github api pulls
7
8387e24 OvO    | ed70a3e feat(fuwari): many personalizations
8
1287507 luyj   | 3df9f6f init(fuwari): by svecco on sve.moe

It’s true that NO ONE has required me to use commit messages like this for my own tiny git repos, but I just can’t help it. It must be because been domesticated by Apache.

1
commit d98176a36a565ec3a47a6a5e52869a2dd6cc36c4
2
Author: Piotr Gankiewicz <piotr.gankiewicz@gmail.com>
3
Date:   Thu Feb 5 15:12:00 2026 +0100
4
"
5
    fix(server): memory leak in segment rotation (#2686)
6

7
    Segment rotation accumulated memory indefinitely because sealed segments
7 collapsed lines
8
    retained their 16MB index buffers and kept file writers open. Under
9
    heavy write load with frequent rotations, this caused memory to balloon
10
    from ~100MB to 20GB+.
11

12
    The fix clears index buffers for sealed segments (when cache_indexes !=
13
    All) and closes their writers immediately after sealing. Writers are
14
    never needed post-seal, and this also releases io_uring/kernel file
15
    handle resources.
16
"

Mysterious Bug#

1
warning: Invalid record ( Producer: 'LLVM21.1.3-rust-1.92.0-stable'
2
                          Reader  : 'LLVM 21.1.3-rust-1.92.0-stable')
5 collapsed lines
3

4
error: failed to load bitcode of module "server-f3f5ee30feef62f6.server.74b6934297a2875c-cgu.0.rcgu.o":
5

6
warning: `bdd` (test "basic_messaging") generated 1 warning
7
error: could not compile `bdd` (test "basic_messaging") due to 1 previous error; 1 warning emitted
8
warning: build failed, waiting for other jobs to finish...

Is there a difference in the space?

CI/CD Workflow#

GitHub Actions#

According to the public standards on GitHub, I initially thought ASF’s CI was paid by them²², because the project is large, there are many compilations, and community are very active.

About Clippy
The uniqueness of a toolchain is jointly identified by its version && hash. Different hashes are regarded as different toolchains.

However, initially, due to system environment issues, the Clippy check could not be run. Since the issue can only be reproduced on NixOS… … and cannot be reproduced on Fedora or Gentoo right now, let’s use the Clippy source code to replace.

1
pub fn compare_rustc_versions(
2
    &self,
3
    current: &RustcInfo,
4
    artifact: &RustcInfo
5
) -> VersionCompatibility {
6

7

8
    if current.commit_hash == artifact.commit_hash && !current.commit_hash.is_empty() {
9
        return VersionCompatibility::ExactMatch;
10
    }
14 collapsed lines
11

12
    if current.version == artifact.version {
13
        return VersionCompatibility::VersionMatch;
14
    }
15

16
    let current_parts: Vec<&str> = current.version.split('.').collect();
17
    let artifact_parts: Vec<&str> = artifact.version.split('.').collect();
18
    if current_parts.len() >= 2 && artifact_parts.len() >= 2 {
19
        if current_parts[0] == artifact_parts[0] && current_parts[1] == artifact_parts[1] {
20
            return VersionCompatibility::MinorVersionMatch;
21
        }
22
    }
23

24
    VersionCompatibility::Different
25
}

1
Detected a version mismatch:
2
        The Rust compiler (rustc) version 1.92.0 (3df9f6f)  used  during
3
        the build process does not match the rustc 1.92.0 (ed70a3e) used
4
        to build the compiled artifact.
5

6
Aborted with 1 error. Clippy check failed.

Obviously, I don’t really want to mess with it, just force it first and see. So this happens often:

Then I felt that something didn’t right, so I check the GitHub Actions Manual, and get this:

Operating system	Billing SKU	Per-minute rate (USD)
Linux 1-core (x64)	`actions_linux_slim`	$0.002
Linux 2-core (x64)	`actions_linux`	$0.006
Linux 2-core (arm64)	`actions_linux_arm`	$0.005
Windows 2-core (x64)	`actions_windows`	$0.010
Windows 2-core (arm64)	`actions_windows_arm`	$0.010
macOS 3-core or 4-core (M1 or Intel)	`actions_macos`	$0.062

1
Permissions Size User   Date Modified Name
2
.rw-r--r--@ 9.4k svecco 13 Feb 21:47  _build_python_wheels.yml
10 collapsed lines
3
.rw-r--r--@  11k svecco 13 Feb 21:47  _build_rust_artifacts.yml
4
.rw-r--r--@  13k svecco 13 Feb 21:47  _common.yml
5
.rw-r--r--@  17k svecco 13 Feb 21:47  _detect.yml
6
.rw-r--r--@ 7.8k svecco 13 Feb 21:47  _publish_rust_crates.yml
7
.rw-r--r--@ 4.6k svecco 13 Feb 21:47  _test.yml
8
.rw-r--r--@ 4.2k svecco 13 Feb 21:47  _test_bdd.yml
9
.rw-r--r--@ 6.6k svecco 13 Feb 21:47  _test_examples.yml
10
.rw-r--r--@  10k svecco 13 Feb 21:47  post-merge.yml
11
.rw-r--r--@  17k svecco 13 Feb 21:47  pre-merge.yml
12
.rw-r--r--@  52k svecco 13 Feb 21:47  publish.yml
13
.rw-r--r--@ 2.0k svecco 13 Feb 21:47  stale-prs.yml

Oh my, the cost would be quite high when the workload is heavy. Although just 2 synchronized by me, there were many others running, too. Anyway, it would be better to mention it to @spetz. I’ve had a fever for the few days at the beginning of 2026 and haven’t been able to work, better nothing serious happens, or I’ll just have to watch helplessly.

Fortunately. Well, although it’s true²³ that Microsoft a sponsor to The ASF, ²⁴ what matters more is this line from @spetz after I asked:

Thank you for all the changes, and dont worry about CI.

Why Not Container?#

My local computing power is just sitting idle anyway, so I may as well put it to use.

Local CI/CD
Since a powerful computer cluster can be shared, running CI/CD on the cloud is generally the recommended choice. As for doing this locally, it seems rather controversial, as it competes for computing power with subsequent development work.

nektos

act

Waiting for api.github.com...

00K

Waiting...

Act is an open source project that provides a way to run CI/CD locally, written in Golang.

Container Option
Act uses Docker to run the CI/CD workflow, which is the default, offering 3 image sizes: micro, medium, and large. In most cases, medium is sufficient. The large version can fully replicate the GitHub CI environment, comes pre-installed with all the toolchains included in the GitHub Actions runner, and can take up nearly 70 GB after decompression.
doas docker images catthehacker/ubuntu:full-latest
1
IMAGE                             ID             DISK USAGE   CONTENT SIZE   EXTRA
2
catthehacker/ubuntu:full-latest   9327301aea27      67.2 GB        16.8 GB
GitHub Runner Micro Docker Image Medium Docker Image Large Docker Image
ubuntu-latest node:16-buster-slim catthehacker/ubuntu catthehacker/ubuntu
ubuntu-22.04 node:16-bullseye-slim catthehacker/ubuntu.04 catthehacker/ubuntu.04
ubuntu-20.04 node:16-buster-slim catthehacker/ubuntu.04 catthehacker/ubuntu.04
ubuntu-18.04 node:16-buster-slim catthehacker/ubuntu.04 catthehacker/ubuntu.04

GitHub Runner	Micro Docker Image	Medium Docker Image	Large Docker Image
`ubuntu-latest`	node:16-buster-slim	catthehacker/ubuntu	catthehacker/ubuntu
`ubuntu-22.04`	node:16-bullseye-slim	catthehacker/ubuntu.04	catthehacker/ubuntu.04
`ubuntu-20.04`	node:16-buster-slim	catthehacker/ubuntu.04	catthehacker/ubuntu.04
`ubuntu-18.04`	node:16-buster-slim	catthehacker/ubuntu.04	catthehacker/ubuntu.04

Always Failed?
Even if some is installed, it may still fail to run, because GitHub Actions runs on fully virtualized machines, while act is based on Docker containers. The former is with the OOM Killer disabled and no seccomp/apparmor security restrictions, it can be more convenient.²⁵

1
# ***wget***
2
wget -qO- https://github.com/nektos/act/releases/download/v0.2.84/act_Linux_x86_64.tar.gz | tar xvz
3
mv ./act /usr/local/bin/act && act --version        # No need use path to run

1
# Golang required
2
git clone https://github.com/nektos/act.git && cd act && go install

However, pulling the full image directly doesn’t seem to work either. This is because GitHub maintains its own official images, while the full version here does not include the Rust toolchain, which causes failures, can not find the rust toolchain or something.

1
# For convenience, Docker will be used directly for demonstration below.
2
doas docker pull catthehacker/ubuntu:rust-latest # Fetch this
3
doas act -P ubuntu-latest=catthehacker/ubuntu:rust-latest \
4
            --platform linux/amd64 \
5
            --container-architecture linux/amd64 \
6
            --pull=false \
7
            --defaultbranch=master \
8
            --container-cap-add SYS_ADMIN \
9
            --container-cap-add IPC_LOCK \
10
            --container-options "--security-opt seccomp=unconfined --security-opt apparmor=unconfined -v /dev/shm:/dev/shm --privileged" \
11
            --verbose

Yay, it compiles! But after a while:

1
|      Summary [ 111.807s] 1250 tests run: 1233 passed, 17 failed, 96 skipped
46 collapsed lines
2
|         FAIL [   0.364s] ( 784/1250) integration::mod cli::personal_access_token::
3
|                                      test_pat_login_options::should_be_successful
4
|         FAIL [   0.199s] ( 814/1250) integration::mod cli::system::
5
|                                      test_cli_session_scenario::should_be_successful
6
|         FAIL [  26.639s] (1129/1250) integration::mod connectors::http_config_provider::
7
|                                      direct_responses::sink_active_config_returns_
8
|                                      current_version
9
|         FAIL [  26.551s] (1130/1250) integration::mod connectors::http_config_provider::
10
|                                      direct_responses::sink_configs_list_returns_all_
11
|                                      versions
12
|         FAIL [  27.207s] (1140/1250) integration::mod connectors::http_config_provider::
13
|                                      direct_responses::source_active_config_returns_
14
|                                      current_version
15
|         FAIL [  27.525s] (1141/1250) integration::mod connectors::http_config_provider::
16
|                                      direct_responses::sink_config_by_version_returns_
17
|                                      specific_version
18
|         FAIL [  28.282s] (1154/1250) integration::mod connectors::http_config_provider::
19
|                                      wrapped_responses::sink_active_config_returns_
20
|                                      current_version
21
|         FAIL [  28.362s] (1156/1250) integration::mod connectors::http_config_provider::
22
|                                      direct_responses::source_config_by_version_returns_
23
|                                      specific_version
24
|         FAIL [   7.141s] (1159/1250) integration::mod server::message_cleanup::
25
|                                      message_cleanup::expiry_multipartition_expects
26
|         FAIL [  28.521s] (1163/1250) integration::mod connectors::http_config_provider::
27
|                                      wrapped_responses::sink_configs_list_returns_all_
28
|                                      versions
29
|         FAIL [  28.885s] (1168/1250) integration::mod connectors::http_config_provider::
30
|                                      direct_responses::source_configs_list_returns_all_
31
|                                      versions
32
|         FAIL [  28.930s] (1170/1250) integration::mod connectors::http_config_provider::
33
|                                      wrapped_responses::sink_config_by_version_returns_
34
|                                      specific_version
35
|         FAIL [  28.913s] (1188/1250) integration::mod connectors::http_config_provider::
36
|                                      wrapped_responses::source_config_by_version_returns
37
|                                      _specific_version
38
|         FAIL [  29.320s] (1236/1250) integration::mod connectors::http_config_provider::
39
|                                      wrapped_responses::source_active_config_returns_
40
|                                      current_version
41
|         FAIL [  29.434s] (1237/1250) integration::mod connectors::http_config_provider::
42
|                                      wrapped_responses::source_configs_list_returns_all_
43
|                                      versions
44
|         FAIL [ 106.101s] (1249/1250) integration::mod connectors::quickwit::quickwit_
45
|                                      sink::given_bulk_message_send_should_store
46
|         FAIL [ 109.062s] (1250/1250) integration::mod connectors::quickwit::quickwit_
47
|                                      sink::given_existent_quickwit_index_should_store
48
| error: test run failed

1
  - target: x86_64-unknown-linux-gnu  # As the arch above, linux/amd64
2
    runner: ubuntu-latest

Judging from the logs, everything points to one thing:

1
failed to start test harness: Health check failed for iggy-connectors at http://127.0.0.1:35235 after 1000 retries
2

3
failed to start test harness: Health check failed for iggy-connectors at http://127.0.0.1:40443 after 1000 retries
4
failed to start test harness: Health check failed for iggy-connectors at http://127.0.0.1:39753 after 1000 retries
5
Received an invalid HTTP response when ingesting messages for index: test_topic. Status code: 404 Not Found, reason: { "message": "index test_topic not found" }
6

7
search: InvalidState{message:"Expected 13 documents but got 0 after 100 poll attempts"}

1
doas (svecco@orion) password:
2
NETWORK ID     NAME                                                      DRIVER    SCOPE
3
8462db97170e   bridge                                                    bridge    local
4
31ea411fde48   host                                                      host      local
5

6
5cefc05182e2   iggy-quickwit-sink-4bd7b25b-36fb-4b04-97f1-ce11755d4322   bridge    local
7
1f577e667a52   none                                                      null      local

1
doas docker ps -a | grep iggy-quickwit | awk '{print $1}' | xargs -r doas docker rm -f
2
doas docker network rm iggy-quickwit-sink-4bd7b25b-36fb-4b04-97f1-ce11755d4322
3
docker container prune -f && docker network prune -f        # Later I did.

Uh? DinD? We may need --net=host attribute.

About Docker-in-Docker
Enables Docker-in-Docker container nesting capability, delivering a clean, isolated solution for containerized CI/CD pipelines, automated image building, environment replication and other container-native workflows, while avoiding dependency conflicts with the host environment.²⁶

About quickwit-sink
quickwit-sink is a core delivery component of the cloud-native containerized logging stack, which streamlines unified log forwarding, indexing and persistence to Quickwit, with out-of-the-box compatibility and lighter configuration overhead for containerized environments.²⁷

You May Have to Edit the Configs Under .github/ to Disable Some Tests

For Features Like CodeCoverage, You May Need a Token for Authentication
When act runs third-party Actions from the GitHub Marketplace (e.g., codecov-action). codecov-action requires a CODECOV_TOKEN (generated from the Codecov platform) to upload coverage reports. A GitHub Personal Access Token (PAT) is optionally needed for GitHub API authentication to reduce the risk of rate limiting, not mandatory for basic functionality. You can generate a GitHub PAT here: GitHub Personal Access Tokens. You can pass secrets to act by using: --secret-file <path/to/token/file>, e.g., add CODECOV_TOKEN=xxx or GITHUB_TOKEN=xxx.

{\large \mathbf{GoodBoy \Longleftrightarrow OneMinBoy♂}}

1
────────────
2
     Summary [ 145.190s] 1454 tests run: 1454 passed (7 slow), 96 skipped
3
Notice: Tests executed in 161s (02:41)
4

5
=========================================
6
All targets build:             17s (00:17)
7
Tests compile:                 30s (00:30)
8
Tests execute:                 161s (02:41)
9
-----------------------------------------
10
Total build:                   47s (00:47)
11
Total time:                    208s (03:28)
12
=========================================

Others#

I’ve been shown!#

²⁸Original Text#
I’m thrilled to see this PR merged ^_^
This is my first ever Rust PR, and also my first contribution to be merged into a formal project that’s nearing 4k stars, rather than a package repo or other casual repositories. As a student, I initially feared the long dev and review cycle would be a hassle, but I’m extremely grateful to @hubcio and @spetz for your unparalleled patience in guiding and reviewing my work, who have helped me get up to speed with the workflow of a production ready backend project. I’ve also learned many things else e.g.podman, and many exp that I’d never get in school.
Thanks, again :)

(Blog of Iggy Release 0.7.0, February 24, 2026)

The Apache Software Foundation, Apache Software Foundation Celebrates 25 Years, Mar. 25, 2024. [Accessed: Feb. 13, 2026]. [Online]. ↩
The Apache Software Foundation, Valuating Code at The Apache Software Foundation, DinoSource, 2022. [Accessed: Feb. 13, 2026]. [Online]. ↩
America’s Cyber Defense Agency, Apache Log4j Vulnerability Guidance, ED 22-02, Apr. 08, 2022. [Accessed: Feb. 13, 2026]. [Online]. ↩
The Apache Software Foundation, Apache Log4j, Dec. 9, 2021. [Online]. (Log4Shell, CVE-2021-44228: Remote Code Execution (RCE) vulnerability, CVSSv3 10.0/10.0 severity) ↩
CrowdStrike, Remote Code Execution (RCE), [Online]. ↩
J. Gardner, Why Java Sucks, Jul. 18, 2017. [Accessed: Feb. 14, 2026]. [Online]. ↩
At my worst during this period, I even forgot the name of the PCIe interface. I didn’t know how to use Tmux either. I truly admire some middle school students who can code proficiently and contribute actively to various projects something I couldn’t do as a high school student. It was not until late 2023 to early 2025 that I gradually got back on track with Ubuntu. ↩
While I have created multiple commits locally, while the remote branch has updated some of these commits via a squash merge, I would create a new branch and then cherry-pick the desired commits one by one … Obviously, rebase --onto is fine. ↩
The Iggy Docs, Apache Iggy Documentation, n.d. [Accessed: Feb. 22, 2026]. [Online]. ↩
Initially, I aimed to avoid division by zero errors by outright blocking any operation that set the value to zero. Later, I noticed that IggyByteSize actually defines a specific meaning for the zero value, so I revised the logic to treat it as “unlimited” to align with the behavior stated in comments throughout the rest of the codebase. ↩
A. Kotsiolis, Simultaneous Multithreading: Driving Performance and Efficiency on AMD EPYC CPUs, AMD Official Blog, Mar. 3, 2025. [Accessed: Feb. 14, 2026]. [Online]. ↩
Rust Team, The Rust Standard Library (std), Commit 01f6ddf75, Feb. 11, 2026. [Accessed: Feb. 14, 2026]. [Online]. ↩
J. L. Hennessy & D. A. Patterson, Computer Architecture: A Quantitative Approach (6th Edition), Elsevier, 2017. [Accessed: Feb. 14, 2026]. [Online]. ↩
Wikipedia Contributors, Non-uniform memory access, Wikipedia, The Free Encyclopedia, 2026. [Accessed: Feb. 14, 2026]. [Online]. ↩
@linux, What is NUMA, and why do we need to understand NUMA?, Zhihu, Linux Server Development Column, Jul. 14, 2023. [Accessed: Feb. 14, 2026]. [Online]. ↩
Crate hwloc: Rust Bindings for the Hwloc library. The hwloc library is a rust binding to the hwloc C library, which provides a portable abstraction of the hierarchical topology of modern architectures, including NUMA memory nodes, sockets, shared caches, cores and simultaneous multithreading. ↩
hwlocality Developers, hwlocality: Rust binding for hwloc, [Online]. (Designed for hardware topology detection, NUMA support, and thread binding optimization; secure, easy to use & actively maintained). [Accessed: Feb. 14, 2026]. ↩
CGPM, SI, Conférence Générale des Poids et Measures. [Online]. [Accessed: Feb. 14, 2026]. ↩
I.E.C., IEC 60027, International Electrotechnical Commission. [Online]. [Accessed: Feb. 14, 2026]. ↩
Wikimedia Foundation, Inc. & I.E.C., Wikipedia, Nov. 2023. [Accessed: Feb. 14, 2026]. ↩
J. Blandy & J. Orendorff & L. F. S. Tindall, Programming Rust 2nd Edition: Fast, Safe Systems Development, Sebastopol, CA: O’Reilly Media Inc., 2021. [Accessed: Feb. 14, 2026]. [Online]. ↩
GitHub Inc, GitHub Actions billing, Docs, Jan. 13, 2026. [Accessed: Feb. 14, 2026]. [Online]. ↩
The Apache Software Foundation, Our Sponsors, Apache Software Foundation Website, 2025. [Accessed: Feb. 14, 2026]. [Online]. (Sponsors, community, projects, and brand information). ↩
The Apache Software Foundation, Our Sponsorship Program, Apache Software Foundation Website, 2025. [Accessed: Feb. 14, 2026]. [Online]. (Sponsors, community, projects, and brand information). ↩
Act, Runners, Act User Guide, 2026. [Accessed: Feb. 14, 2026]. [Online]. ↩
Meta Inc., What is ‘DinD’? Llama 4 Scout, Feb. 14, 2025. [Accessed: Feb. 14, 2025]. ↩
Meta Inc., What is quickwit-sink? Llama 4 Scout, Feb. 14, 2025. [Accessed: Feb. 14, 2025]. ↩
@Svecco, Code 3858794990 Comments, GitHub, Apache Iggy Pull Request #2452, Feb. 6, 2026. [Accessed: Feb. 6, 2025]. [Online]. ↩

How I Discovered#

The ASF#

The Apache Iggy#

Ask for Assignment#

Pick Up One Issue#

Ask the Collaborators#

Get On Work#

Preparation#

Learn the Structure#

Implementing Feats#

Panicked OOM Code 12 with 44GiB RAM Empty?!#

Limitations¹² / `pub fn available_parallelism() -> Result<NonZero<usize>>`#

Wait, Some Compiling Dependencies Missing#

IEC != SI#

Are You Sure#

Make a Clean Git Log#

Mysterious Bug#

CI/CD Workflow#

GitHub Actions#

Why Not Container?#

Others#

I’ve been shown!#

²⁸Original Text#

How I Discovered#

The ASF#

The Apache Iggy#

Ask for Assignment#

Pick Up One Issue#

Ask the Collaborators#

Get On Work#

Preparation#

Learn the Structure#

Implementing Feats#

Panicked OOM Code 12 with 44GiB RAM Empty?!#

Limitations12 / pub fn available_parallelism() -> Result<NonZero<usize>>#

Wait, Some Compiling Dependencies Missing#

IEC != SI#

Are You Sure#

Make a Clean Git Log#

Mysterious Bug#

CI/CD Workflow#

GitHub Actions#

Why Not Container?#

Others#

I’ve been shown!#

28Original Text#

Footnotes#

Limitations¹² / `pub fn available_parallelism() -> Result<NonZero<usize>>`#

²⁸Original Text#