SD-hostile logging and journaling defaults on Raspberry Pi OS #7234
Description
Describe the bug
Dear Raspberry Pi OS maintainers,
I am writing to raise a design-level concern about Raspberry Pi OS defaults on SD-card–backed systems. This is not a support request, but a report of a systemic failure mode that arises from treating SD storage as if it were durable logging media.
By background, I have approximately forty years of professional computing experience, am a qualified Unix system administrator, and hold a degree in computer science. The observations below are technical, reproducible, and concern architectural assumptions rather than user error.
Summary
Raspberry Pi OS combines ext4 journaling, system logging, and background metadata churn on SD cards in a way that is fundamentally hostile to the characteristics of SD media. The result is avoidable wear, fragile recovery behaviour, and failure modes that force users to re-flash rather than repair, even when user data is intact.
Core issue
SD cards are wear-limited, extremely sensitive to small random writes, opaque in their internal failure modes, and intolerant of power loss during metadata updates. Despite this, Raspberry Pi OS defaults treat SD cards as if they were server-grade block devices, with ext4 journaling enabled by default, continuous logging activity, frequent metadata updates, and no clear user-level control over logging aggressiveness or recovery semantics.
Logging and journaling are not normal data. They are high-churn, low long-term value, often discardable, and should be explicitly survivable or explicitly lossy. On SD media, treating them as first-class persistent data is actively harmful.
Observed consequences
In practice this leads to premature SD card wear, unclean shutdowns during log or journal writes, ext4 journal recovery failures that are difficult to diagnose, recovery deadlocks when cloning SD cards (a common and encouraged workflow), and users being forced to re-flash rather than repair.
In a recent incident, an ext4 journal recovery deadlock occurred when attempting to repair a cloned SD card via USB. While ext4 behaved conservatively, the root cause was not the filesystem itself but the volume and nature of writes imposed on SD storage by default OS behaviour.
Why this is a Raspberry Pi OS problem
This is a policy issue, not a mechanism issue. ext4 is behaving as designed. The problem is that Raspberry Pi OS uses SD cards as the primary root medium, encourages cloning and reuse, expects power loss and abrupt shutdowns to be normal, yet applies logging and journaling policies appropriate to very different storage classes.
Suggested directions
At minimum, it would be valuable to consider SD-aware defaults for logging, clearer separation between user data and logging or journaling churn, documented and supported SD-safe filesystem configurations, and recovery paths that acknowledge SD unreliability as a first-class constraint.
Closing
This is not a complaint about ext4, nor about Linux in general. It is an observation that Raspberry Pi OS defaults implicitly assume storage characteristics that SD cards simply do not have. The resulting failures are not edge cases; they are normal outcomes of normal use.
I am cc’ing the ext4 maintainers for visibility, as this issue sits at the boundary between filesystem safety mechanisms and embedded-system policy decisions.
Regards,
Steps to reproduce the behaviour
Happened randomly due to non SD design
Device (s)
Raspberry Pi 5
System
Raspberry Pi reference 2024-11-19
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 891df1e21ed2b6099a2e6a13e26c91dea44b34d4, stage4
2024/09/23 14:02:56
Copyright (c) 2012 Broadcom
version 26826259 (release) (embedded)
Linux xi3r 6.12.20+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.20-1+rpt1~bpo12+1 (2025-03-19) aarch64 GNU/Linux
Logs
No response
Additional context
Wasted several days trying to work around this but kernel blocks all attempts - would involve significant work and risk to rebuild and copy all data from a fine file system