On 12/26/22 13:44, Jeffrey Walton wrote:
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.
While I think they do wear leveling. however my busiest sd card is a
64Gb in an rpi4b that also has a couple even bigger SSD's mounted by way
of usb3 disk adaptors, and everything of a high traffic nature other
than the os itself, has been moved to the SSD's. I build from git pulls
or install 60 megs worth of linuxcnc almost daily and that traffic of
the install goes to the u-sd card. That 64GB card was new in May 2016
for a jessie install, the realtime kernel I built for LinuxCNC was
installed in Feb 2020 after I'd rebuilt it for the rpi4b as it started
out on an rpi3b. It is still working fine, and I am convinced it is
because the wear leveling has room to play. A df report:
pi@rpi4:~ $ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 61064956 21638960 36863232 37% /
devtmpfs 959080 0 959080 0% /dev
tmpfs 992872 0 992872 0% /dev/shm
tmpfs 992872 67016 925856 7% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 992872 0 992872 0% /sys/fs/cgroup
/dev/mmcblk0p1 258095 66664 191432 26% /boot
/dev/sdb1 229700940 109273548 108689536 51% /media/pi/workspace
tmpfs 198572 4 198568 1% /run/user/1000
/dev/sda3 91332952 57368 86593108 1%
/media/pi/1485dff1-c61f-4bb0-a1c8-26f5201696fb
/dev/sda1 2573384 67468 2505916 3% /media/pi/boot12
/media/pi/workspace is a 240 GB SSD where most of the traffic goes,
while /dev/sda2 is 9.9 GB of swap, 70 megs in use, sda is a 120GB
kingston SSD. It has a small cyberpower ups and I have standby power so
it does not see power failures.
uptime is:
pi@rpi4:~ $ uptime
15:21:08 up 70 days, 2:00, 3 users, load average: 0.02, 0.07, 0.24
The card seems perfectly healthy yet and will be 7 years old next May.
And yes, I did rather quickly destroy a 16GB card that had less than 5GB
on it when it quit.
Will it die yet today? IDK.
And is there a way to detect pending failures like this before they
bite?
Not that I know of, smartctl is rather crippled for u-sd's but seems to
work ok with the SSD's.
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
.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
