SD-hostile logging and journaling defaults on Raspberry Pi OS

The issue names Raspberry Pi OS generated with pi-gen stage4 at commit 891df1e21ed2b6099a2e6a13e26c91dea44b34d4, but no file, test, or concrete change is identified. Start by reviewing the stage4 defaults and narrowing the logging, journaling, or recovery behavior into a reproducible failure. Done would require an agreed SD-aware default or recovery change with a clear acceptance criterion.

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,

Ed Darnell

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