On Mon, Dec 26, 2022 at 1:25 PM Tim Woodall <debianu...@woodall.me.uk> wrote: > > [...] > > It had a 16GB sandisk microSD card although I was only using c 3GB at > the beginning. > > On 21st December the kernel remounted the card ro - but (almost) > everything continued to work - my daily backups take a snapshot (which > failed) and the daily 'I'm alive' email also failed. Both of these > generated an 'URGENT' email from my monitoring scripts. As the AP and > routing were both fine I investigated at the weekend. > > What I found was the beginning of the card was unwriteable, I've not > investigated exactly how much, while the rest of the card seems > perfectly OK. I cannot, for example, change the partition table, nor can > e2fsck clear the dirty journal flag, nor could I change cmdline.txt but > my quick sampling didn't find anything else that was unwriteable. > > Do these cards have wear levelling? Have I just got unlucky that it's > the start of the card that is unwriteable and so I cannot continue on > the 12GB of space that has never been part of a partition?
Yeah, SDcards wear out. I don't know if they perform wear leveling and such. I use RPI's to test Botan, Crypto++ and OpenSSL on armel (RPI-1, armv6), armhf (RPI-2, armv7-a) and arm64 (RPI-4, aarch64). I put a swap file on them to avoid OOM kills when running the C++ compiler.[1] I eat a SDcard every 6 months or so. > And is there a way to detect pending failures like this before they > bite? Don't know. I don't believe SDcards have SMART monitoring. I usually wait until I get unexplained file system errors, and then throw the card away. For me, the file system errors usually surface on an `apt update && apt upgrade`. Jeff
