cam94z28

I had been backing up several computers on my local network at once to my Unraid Array. I noticed my cache drive was filling up. I intended for Write_Cache to be set to "No", but forgot I had set it to "Yes". I tried to invoke the mover several times, and nothing happened, so I paused all backups. I invoked the mover again and still nothing, but mover said it was running. Finally, I decided to change Write_Cache to 'No', So It would write to the array. When I selected save, I received the message "The share was deleted". I checked the share page and all shares were deleted. Is there any way to get these back? The write cache drive is still showing 97% full with the data it had before. EDIT: After a shutdown/power on they came back. whew! I was worried for a minute. Still no idea what could cause that.

I was actually replying to Gregorg but forgot to quote. Thank you. That makes sense. I will increase minimum free space, and go with it.

Thank you. The word "Prefer" makes it confusing, but the text at the right in the share settings makes it clear. I changed to 'Yes', stopped the mover from the terminal ('sudo mover stop', and re-ran it. Now, it is reading from the cache and writing back to the array. I will try the mover tuning plugin and also install the appdata backup plugin, as my pools are single-drive. Just out of curiosity, with things set to 'Yes', is there any protection from the drive filling up during the process?

I have just added two spare SSD's. I setup one as 'apps' to store appdata, system, docker image, etc... and a public share with common files, installers, etc... Another to be used as a write_cache for files written to the server. Maybe I don't understand the settings properly, but when set the write cache to 'Prefer', and manually run the Mover, it's writing files to the cache drive from the array. Is the only way to have the opposite occur, to set the share to 'Yes' and risk it filling up completely?

Problem appears to be solved. Came home to a completed parity-check notification and a running server. Thanks for the advice.

Thanks, I see it now. I must have missed the text that clearly said Ryzen. I have plenty of old SSD's laying around, so I definitely plan to install a cache drive (or pool). I have been avoiding it as there's nowhere to really mount them easily in this ancient case. My server was basically idle, other than the parity check running. No docker containers or VM's running, and no active file transfers, so the drives did manage to power down. I came home today to an unresponsive server again. Cannot load the web interface, and it isn't responding to pings over the network. It still hasn't finished a successful parity check, due to freezing. Only option is to long-press the power button to power cycle. I will attach the syslog I was mirroring to flash. I already looked it over, and there doesn't appear to be much that happened since I logged out last night. Maybe you will catch something I missed. Meanwhile, I will take a look at the BIOS for settings related to C-States. EDIT: My BIOS Has "Global C-State Control". It also has "Power Supply Idle Control" with Auto, Low Current Idle, and Typical Current Idle as options. It was set to 'Auto'. I'm assuming the latter is going to be the one to focus on? Changed the "Power Supply Idle Control" as outlined in the FAQ. Crossing my fingers for a successful parity check. syslog

I can't seem to find the original thread with the Ryzen link. I must have closed the tab. Unless you are referring to the syslog server link. I have just enabled syslog mirroring to flash. Hopefully I can catch the next crash. Was the array offline? I will attach another diagnostic. Parity check is currently running. Hopefully that counts. antec300-diagnostics-20220416-0028.zip

Point taken. Thank you for the common sense support. Attached is my diagnostics file. Something else to add. I have my hard drives set to 15 minute spin-down delay. When the freeze has occurs, it's usually down to the parity drive and one remaining drive still online. The identical setup (other than RAM, Motherboard, CPU), was working perfectly on an FX-6300 with MSI 970A Krait SLI Motherboard. antec300-diagnostics-20220415-2324.zip

FWIW, I'm having a similar issue with a Ryzen 7-1700 on a MSI B350 Tomahawk Motherboard. It will run fine for many hours, then just randomly freeze. I had to run a parity check on one drive yesterday after bumping the USB stick (I know should move it to one of the rear ports), and temporarily wiping out the license info. I left it on last night, and today for the entire day at work. I came back to see the monitor still powered on (video signal), but the server totally unresponsive. Apparently it never finished the parity check in that time because it restarted after i restarted it. . Many times it does not come back from a reboot, either. I have to shutdown, and manually power back on instead.