SD Card corruption again, again

Phaedrux

What level of logging are you using? What is the command used?

gnydick

@Phaedrux
M929 P"eventlog.txt" S1

jrockland

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.

gnydick

@jrockland i don't think < 1GB would do that.

jrockland

@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

@jrockland **those where from when I was running with attach rasp boards..
Probably much smaller now.

gnydick

@jrockland exactly, i had just emptied my card recently.

jrockland

@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.

gnydick

@jrockland believe me, I understand. I regularly delete my files because it's too much to scroll through on the paneldue.

o_lampe

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.

chrishamm

@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.

o_lampe

@chrishamm said in SD Card corruption again, again:

trim support

That was the term, I was looking for. IIRC someone implemented it for SD-cards, too. Now with the right term to look for, I'll find it back. Although it might not be needed for newer cards.

Thanks again Chris

gnydick

@chrishamm even without TRIM, they still do write-leveling, which is what you're referring to.

DekJak

This post is deleted!

DekJak

Hi, I just had this problem too.
I used the printer a couple of weeks ago without problem.
Today, when I turned the machine on there are no files on the SD card.
I don't log to the SD
The SD card is the one that was supplied with the duet.

What's the best way to recover from this?

Best
DerekJ

DekJak

@DekJak said in SD Card corruption again, again:

Hi, I just had this problem too.
I used the printer a couple of weeks ago without problem.
Today, when I turned the machine on there are no files on the SD card.
I don't log to the SD
The SD card is the one that was supplied with the duet.

What's the best way to recover from this?

Best
DerekJ

Hi Again,
Just read the SD card in a computer reader and all files are on the card.
Popped it back into the Duet and all OK again now.
Must have been the re-seating that fixed it.
DerekJ

gnydick

@DekJak I frequently back up my card now. You can select all files in the DWC and download as zip.