SD Card corruption again, again
-
what does an ups have to do with logging?
-
@Phaedrux it's not that much writing, really. the cards have write leveling. considering it's a 32GB card, it will take a VERY long time to wear down the card.
-
How corrupt are the cards? Can they be reformatted and reused or are they unusable once they fail?
-
Silly question, but where are you buying them ?? I've had a couple permanently fail, and even though they were supposedly 'branded' items, I doubt they were as they were a lot cheaper than others.
Also try connecting them to a PC, whether Windows or Linux, & re-formatting them, I've resurrected a few that way....
-
@Veti said in SD Card corruption again, again:
what does an ups have to do with logging?
I don't see any other reason to have logging "always-on" except if you want to have data to continue after power loss. This is better solved by UPS. For any other reason, it would make sense to log from time to time to check issues if you have them, but not always.
32G is a big card, you are probably writing over and over the same place if they are getting worn out quickly (many will lock the card for writing into read-only mode when they encounter write issues and cant remap the blocks any more, many will not fail on writes but silently ignore them). Possible solution would be to either never delete log files and only create new ones or always append to a log file and not truncate it ever. I have no clue how M929 actually work, never had a need for it, I have enough issues with crappy SD cards to force them to take the logging data too... tried many years ago with marling and gave up after few dead cards
-
powerloss recovery is M911 and not debugging.
those are two different things. -
@Veti yes, my mistake, you are only logging basic stuff (Start, stop ..) that should not eat up the SD card, not enough "traffic" ..
-
i think it logs every move. so its a lot
-
@Veti it does not log every move. that would be silly.
-
What level of logging are you using? What is the command used?
-
@Phaedrux
M929 P"eventlog.txt" S1 -
The problem doesnt come from the boards.
I use multiple duet3d boards with all kind of sd cards and never had that issue.
You might have fakes from amazon/ebay: They look 100% like the real one but are 8g instead of 32g, and as the board think they are 32g it keep writing and destroy the card.I even once bough a fake from walmart. No joke. It is hard to find good stuff now.
-
@jrockland i don't think < 1GB would do that.
-
@gnydick depend how many projects you have on those cards.. my cards usually run around 12+ g when I back them up. But im running a ton of high def projects..
-
@jrockland **those where from when I was running with attach rasp boards..
Probably much smaller now. -
@jrockland exactly, i had just emptied my card recently.
-
@gnydick I creat/test/bench printers parts, so when I want them to go trough a 72hrs+ hardcore run you should see the size of the gcode files..... even just a "circle" with 4096 sides is impressive.
-
@jrockland believe me, I understand. I regularly delete my files because it's too much to scroll through on the paneldue.
-
I can add my findings about counterfeit SanDisk SD-cards. Not related to size (8GB vs. 32GB) but related to write speed. Some of the cheaper cards I wrote (Linux) images to with Balena Etcher showed a much slower write speed.
There is another thing, I saw in Linux world, which might come handy for Duet3D too:
Most SSD-drives have a write-wear protection that randomly uses different areas in the memory-address room. Someone in the RasPi-world has implemented that feature for SD-Cards, too.
@chrishamm (hint, hint) sorry to bother you again
Especially when you regularly delete files, that would be helpful, since otherwise, the logging would take place at the same memory-addresses over and over again.
-
@o_lampe Newer SD cards have an embedded controller that ensures data isn't always written to the same physical location (like modern SSDs). For IO-intense purposes it's probably a good idea to replace the standard SD cards with A1/A2-certified cards. I generally use a SanDisk A2 card for DuetPi tests, especially because of the speed advantage compared to other cards.
For quite some time ext4 (the FS used by Raspberry Pi OS and DuetPi) has enabled trim support automatically on supported platforms but I must admit I am not 100% sure if that particular feature is available with SD cards.
Duet software engineer
