What you’re describing is termed wear leveling.
SD cards with wear leveling are now fairly common.
If the card has WL, then the answer to both questions is yes.
Info on Western Digital Purple SD cards:
From the link shown above:
Designed and tested to withstand 24/7 continuous write workloads, meet data retention requirements, and accommodate harsh environmental conditions, the industrial SD and microSD cards and WD Purple microSD cards are ideal for low footprint, local storage at the surveillance edge, working in concert with other Western Digital solutions in on-premises DVRs and NVRs, in near-edge cloud servers and in back-end cloud data centers.
12 USD for a 64 GB µSD card.
https://shop.westerndigital.com/products/outlet/memory-cards/wd-purple-microsd#WDD064G1P0A
Sounds like this puppy is just the ticket. Price is £18.49 for a 64 GB µSD card.
UK supplier:
Some interesting info on wear leveling:
Thank you. I assume the wear levelling algorithm runs directly on the SD card itself, and not on an external (i.e. on the Pi) controller?
(Which means the WD SD card is so much more than just 512 billion on/off switches)
I note also the WD SD card on Amazon makes no mention of wear levelling - so buyers may need to dig deeper. More discussion here:
Read/Write cycles of a SD card - Raspberry Pi Forums (which also answers my question above)
Correct.
The card on the Amazon page is the WD Purple, which does employ wear leveling.
That’s why I posted the link to WD’s product info page.
https://www.westerndigital.com/products/embedded-removable-flash/surveillance-sd-microsd-cards
On that page:
Advanced firmware memory management features, including power immunity, auto/manual refresh, ECC, and wear-leveling
Ordered one and will give it a try, not having much luck with my ordinary Sandisk sd card right now…
Was cheaper from Western Digital themselves than Amazon (but watch out for £6 postage on top).
Below is a link to a thread on the Raspberry Pi Forum, providing an app that can read out the current ‘health’ status data for two Industrial class microSD cards: those from SanDisk / WD, and those from Apacer and offshoots.
This allows say weekly monitoring this status (equivalent to on an SSD comparing TBW to rated max TBW). To track that the device does not exceed lifetime limits.
https://forums.raspberrypi.com/viewtopic.php?p=1988851
William
1 Like
The Meteobridge weather station software/weather data server for RPi can only be used with a limited range of industrial SLC cards, as stated on following link.
https://www.meteobridge.com/wiki/index.php/Hardware#Raspberry_Pi_Model_3B.2C_3B.2B.2C_4B
2 Likes
re: Meteobridge limited range of industrial SLC cards
That list does include both the cards supported by the Raspberry Pi microSD ‘health check’ app (‘sdmon.c’): SanDisk/WD and Apacer. Both types of NAND cells: SLC and MLC.
My impression is that WITH all of the extensive robustness features of the SanDisk Industrial cards (ECC, wear leveling, read disturbance correction, powerfail protection, etc.) – that MLC is now on par with the range of endurances offered by SLC. At a fraction of the cost. See the SanDisk / WD doc, with listed TBW figures:
I agree, we’re now using industrial grade SD cards as standard in all OpenEnergyMonitor units. We’re currently using SanDisk SDSDQAF3-016G-I
It would be very interesting if we could read the health status of this card!
Glyn, hi.
I have this same type of SanDisk Industrial card, and the ‘sdmon.c’ previously mentioned program DOES read out the health status. See the Pi Forum link I mentioned previously to download the zip file containing sdmon.c and the Makefile.
https://forums.raspberrypi.com/viewtopic.php?p=1988851
Regards, William
Ah that’s cool!
I’ve just tested for myself, the pre-compiled release gave lots of errors, so I compiled it. I’m now getting less errors but no reading
git clone https://github.com/Ognian/sdmon
cd sdmon/src
make
I’ve tried with and without the -s parameter. Any idea what I’m missing?
pi@emonpi:~/sdmon/src $ sudo ./sdmon /dev/mmcblk0
{
"version": "",
"date": "2022-04-08T02:29:52.000Z",
"device":"/dev/mmcblk0",
"idata.response[]":"0x900 0x00 0x00 0x00",
"error2":"2nd CMD56 CALL FAILED: Connection timed out"
}
pi@emonpi:~/sdmon/src $ sudo ./sdmon -s /dev/mmcblk0
{
"version": "",
"date": "2022-04-08T02:30:34.000Z",
"usage":"wrong argument count"
}
Glyn, hi.
Ognian has not yet incorporated the SanDisk mods. That is why I posted my zip on the Pi Forum thread. It might take him some days or a week or so to merge my mods. His current version does not understand the ‘-s’ or ‘-a’ switches.
Just download my zip and build that, then “sudo ./sdmon -s /dev/mmcblk0”
William
1 Like
The sdmon.c may also assume you are running a 64 bit Pi OS. That’s what I have here. Have not tested on 32 bit Pi OS. If you have 32 bit and it works ok, let me know. All the #includes should account for this automatically…
I’ve just tested your version of sdmon from the RasPi forums on my an emonPi with 32-bit Raspberry Pi OS, and it worked!
{
"version": "0.01",
"date": "2022-04-12T14:50:32.000Z",
"device":"/dev/mmcblk0",
"manufactureYYMMDD": "210712�|���R��������T��p���",
"healthStatusPercentUsed": 1,
"featureRevision": "0x1f",
"generationIdentifier": 5,
"productString": "SanDisk ",
"success":true
}
I’ll await these changes to be built into the Ognian git repo, then look at a way we can get this info displayed on the admin panel in Emoncms on the emonPi.
Glyn, hi. Just sent you an email.
The zip posted on the Pi Forum has been updated to fix the minor string termination glitch you saw. As far as I know Ognian is still in progress on the merge to his Github repo.
Regards, William
1 Like