Coredumps delivered over Unix domain sockets can now be written as sparse data under code merged for the Linux 7.4 kernel, cutting dump sizes dramatically — in the most extreme cases down to roughly 1% of what the same dump would occupy without the feature, according to Phoronix.
The change builds on a mechanism the kernel gained only in the last development cycle: the ability to route coredumps to a listening Unix domain socket rather than only through the traditional pipe-based path. That original work gave systems a way to hand crash dumps to a remote or separately supervised collector process instead of tying them to a pipe target configured in the kernel's core pattern. Sparse support, now landed for 7.4, is the follow-on refinement: instead of writing out every page of a crashed process's address space, the kernel can skip regions that contain no meaningful data, transmitting only what actually matters.
The size difference can be substantial because a large share of a typical process's virtual memory is unmapped, zero-filled, or otherwise uninteresting for post-mortem analysis. A coredump written naively materialises those regions anyway, producing multi-gigabyte files that are slow to write, expensive to store, and cumbersome to transfer off-box. With sparse handling in place, those regions are simply omitted, and the receiving end reconstructs the layout — meaning the on-the-wire and on-disk footprint reflects the dump's real informational content rather than the full span of the address space.
For anyone who operates Linux systems for a living, the practical implications are straightforward. Crash dumps from large services and databases routinely run to many gigabytes; teams that retain them for debugging, that ship them to a central crash-handling service, or that archive them for compliance and regression analysis all pay for that volume in storage, bandwidth, and time-to-diagnosis. A coredump that arrives at one-hundredth of its former size changes the economics of keeping dumps around at all — and makes it feasible to collect them from machines or environments where dumping a full core was previously impractical.
It is worth noting the caveats behind the headline figure. The 1% number represents an extreme case rather than a typical outcome; the actual saving depends entirely on how much of a given process's memory is genuinely empty, and workloads with densely populated address spaces will see correspondingly smaller reductions. Real-world savings also hinge on the receiving side: debuggers, crash daemons, and storage formats downstream of the socket need to correctly consume sparse dumps for the benefit to fully materialise. Any organisation evaluating the feature should validate its existing tooling chain before assuming the reduction will carry through end to end.
The feature's arrival in 7.4 continues a broader shift in how the kernel treats crash handling as a pluggable, network-adjacent concern rather than a purely local filesystem one.
Developers and administrators running mainline or near-mainline kernels should expect to see the option become available as 7.4 moves through release, with the usual caution that adoption depends on both kernel support and updated receiving-side tooling.
Source: Phoronix — https://www.phoronix.com/news/Linux-Coredump-Sockets-Sparse
據 Phoronix 報道，已合併至 Linux 7.4 kernel 的代碼，令透過 Unix domain socket 傳送的 coredump 可以稀疏（sparse）數據形式寫入，大幅縮減 dump 體積 —— 在最極端的情況下，體積可降至同等 dump 在沒有此功能時的大約 1%。
此項改動建基於 kernel 在上一個開發周期才引入的機制：將 coredump 引導至監聽中的 Unix domain socket，而非僅沿用傳統的 pipe 路徑。該項原有工作讓系統得以把崩潰 dump 交予遠端或獨立監管的收集器進程（collector process），不再局限於 kernel core pattern 中設定的 pipe 目標。現已登陸 7.4 的稀疏支援屬後續改良：kernel 無需寫出崩潰進程位址空間的每一頁，而是跳過不含任何有意義數據的區域，只傳送真正重要的內容。
體積差異可以相當可觀，因為典型進程的虛擬記憶體有很大比例屬於 unmap、填滿零值，或對事後（post-mortem）分析毫無價值的部分。以最直接的方式寫入 coredump 時，這些區域一律會被實體化，產生數 GB 計的檔案，寫入緩慢、儲存成本高，亦難以傳輸到機器以外。有了稀疏處理，這些區域會直接略過，由接收端重建佈局 —— 也就是說，傳輸中及磁碟上的佔用量反映的是 dump 真正的資訊內容，而非位址空間的完整跨度。
對於以營運 Linux 系統為業的人士而言，實際影響相當直接。大型服務及數據庫的崩潰 dump 動輒達到數 GB；無論是為偵錯而保留 dump、將其傳送至中央崩潰處理服務，還是為合規及回歸分析而存檔的團隊，都要為這方面的儲存空間、頻寬及診斷所需時間付出成本。當 coredump 體積縮減至原來的百分之一，保留 dump 的成本效益將完全改觀 —— 亦令以往不切實際地 dump 完整 core 的機器或環境，亦可收集 dump。
值得留意的是，標題數字背後的限制。1% 屬極端個案，並非一般情況；實際節省幅度完全取決於指定進程的記憶體中有多少部分確實是空白，位址空間使用密集的工作負載所獲得的降幅自然較小。實際節省亦取決於接收端：socket 下游的 debugger、crash daemon 及儲存格式必須正確處理稀疏 dump，效益才能完全落實。任何機構在評估此功能前，應先驗證現有工具鏈，方能假設縮減幅度可全程貫徹。
此功能登陸 7.4，是 kernel 將崩潰處理視為可插拔（pluggable）、與網絡相關而非純粹屬於本機檔案系統事宜的更大轉變之一環。
運行 mainline 或接近 mainline kernel 的開發者及管理員，可預期此選項會隨 7.4 的發布進程逐步提供；一如既往需注意，能否採用同時取決於 kernel 支援及接收端工具的更新。
Source: Phoronix — https://www.phoronix.com/news/Linux-Coredump-Sockets-Sparse