Kagoromo

Hi JorgeB, thank you for your suggestion, and sorry about not replying until now. After a few hours that day, I decided to abandon the cache altogether and rebuild the Docker containers from the latest backup. Thanksfully that went well and the unraid box has been running nicely since then. Right now I have all shares (including appdata and system) running straight from the array, to avoid SSD shenanigans. 1 of the SSDs was indeed dead, so I just use the remaining one as a pure write cache now.

Today I woke up to find 1 SSD of the 2 assigned to the cache missing. I disabled Docker, did a full shutdown then boot it up again. The array failed to start by itself, as 1 of the 2 SSD was still missing. I tried to start the array anyway and it did, with the cache still unavailable. Is it possible to recover data on the cache? There is only Docker appdata there, and I have weekly backups so it's not too bad if it's lost, but still would be nice to have the thing running until new SSDs arrive. Diags attached. tower-diagnostics-20230901-0935.zip

I would like to forth that. Also attaching my diagnostics. tower-diagnostics-20230415-2203.zip

Hi, the problem went away for me after I moved the printer closer to the Unraid machine to avoid having to use a long USB extension cable. I also bought a new USB mini cable just in case, but it turned out to be unnecessary as the cable that came with the printer worked just fine as long as it's plugged straight into the Unraid machine. If you have been using a USB extension cable, that's where I'd take a look first.

Hi, firstly thank you for maintaining this Docker! I need a few pointers to troubleshoot intermittent USB connection to the printer. System log when such disconnection happens: Jul 13 12:45:52 Tower kernel: usb 2-1.2: new full-speed USB device number 23 using ehci-pci Jul 13 12:45:52 Tower kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device Jul 13 13:20:03 Tower emhttpd: spinning down /dev/sde Jul 13 13:40:09 Tower emhttpd: spinning down /dev/sdb Jul 13 13:42:22 Tower emhttpd: read SMART /dev/sdb Jul 13 15:22:08 Tower kernel: usb 2-1.2: USB disconnect, device number 23 Jul 13 15:22:08 Tower kernel: usb 2-1.2: new full-speed USB device number 24 using ehci-pci Jul 13 15:22:08 Tower kernel: cdc_acm 2-1.2:1.0: ttyACM0: USB ACM device And the error as shown on Octoprint: State: Offline after error SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?) Printer is Artillery Hornet. Octoprint generally works well except for these random disconnections which may happen anytime, during an auto bed leveling routine, mid-print, pre-heating. Diag zip is attached. Thanks in advance! tower-diagnostics-20220713-1535.zip

Hi, big thanks to OP for figuring all these fixes out. I have a docker app that writes to a redis db (some 50 MB large) every few seconds and your ramdisk trick really helped taming the cache write. I just want to add a note that, if you do go ahead with the 'appramdisk' route, the container's appdata path also has to be modified to use that appramdisk on top of all the scripts that you created. It took me an embarrassingly long time to figure out why the cache was still constantly having ~10 MB/s written to despite the appramdisk script up and running. Hope that can help someone else!