theruck

similar question here. i just heard that my unraid server rebooted and i cannot find a reason while i know it was not me rebooting it or me having any automatic action that would do so server-diagnostics-20231215-1149.zip

there was no way out other than reboot as you can see array is starting but parity check buttons are not there the next teboot the parity check started as you described

after another reboot all is looking ok again and the array starts normally starting a parity check server-diagnostics-20221201-1045.zip server-syslog-20221201-0945.zip

did a clean reboot after changing CPU pinning and getting this after start the array is in starting... state

create a working VM clean then use the imported vmdk file as drive (replace file if possible) to be sure you have a working configuration first

are you copying to a SSD drive on the unraid server?

then you need to try different filesystem or use disk shares instead

try to list the directory with different command if it take so much time too as it might be caused by ls itself. try find or use ls without the sorting - ls -U should be quicker also coloring of files in bash can have an impact on the output it can be also filesystem dependent so you can have different results using XFS

you would know it by the amount of data you need to - copy quickly - have available on the quicker SSD drive due to performance - be proteced thus stored on the HDD with parity as the SSD data is not protected by parity so it really comes up to your use case and type of data and type of storage requirements

your bottleneck is the hard drive speed so you can solve this with a SSD or SSD cache drive only. you would need to size the SSD cache drive properly for your use case.

only if your use of the quicker cache drive requires higher than current cache drive capacity

its kernel functionality and as you already know with the S3 sleep plugin the sleep is possible and used by hundreds of users so it is well tested as well you understood nothing from this topic but that is your shame not mine we are in 2022 and it has been many many years since any modern filesystem does not get corrupted with dirty shutdowns. not during machine sleep. No car maker is going to call your car to the service once your oil light has come on for a second - inadequately assuming that your engine is corrupted - this is what unraid does today with our parity. wake up man you are full of nonsense this is about parity check not about data integrity on the filesystem. you probably do not understand the topic but your parity even when your servers are on UPS are not any cleaner than mine is after the dirty shutdown. you know the parity quality only after the finished check and since that moment you can have corrupted parity due to failing drive or memory module so you really need to get your stuff together before posting such BS

if you can afford smaller outages i would consider to build a parallel unraid server with 8 drives and copy it over

yes even ssd drives fail...

how much data in total you have?

this happened to me recently too. i had one intel 660p nvme ssd which i started to clone/image to another drive and it died during the process it was causing my bios to freeze on the reboot or was u detected not much you can do about it. it happens if it does not read 2 drives on the same port/slot then it might be a faulty controller port you need a different pc or usb enclosure to confirm the actual drive is ok

how do i send it to you?

have you ever tested it? on the reboot the plugin says it will continue after reboot but after a clean reboot the OS says Parity is valid and the scheduled parity check from the plugin never starts

well then i live with this bug

how is it different? if you cannot guarantee the on state for the parity check duration and you dont have the plugin installed there is nothing you can do because Limetech always expects that your parity needs a check after a dirty reboot and always expects that your parity is in tact after a clean reboot. it is always a very primitive guess about your parity state based on poor assumptions so never ever believe what is written in the GUI as you always have check if the last parity check ran sucessfully until the finish and still most probably the automatic parity check has been ran with auto correct parity option which is not what you want to do on the first run as explained here

by the way you guys seem to not know this if you have a dirty reboot and the parity check starts then you do a CLEAN REBOOT of the system before the parity check finishes next reboot you get a miracolous Parity is valid! So much for all the suggestions and BS about UPS and clean shutdowns and how Limetech cares about your data. As i stated in this topic its all a very unqualified and primitive guess that the parity needs a check and in situations when it actually needs a check it either does not think it is needed or overwrites your correct data with data from a failing parity drive without any notification to you, users.

thanks that could actually be quite nice solution anyway it is not comparable with windows as windows does not have a journaled filesystem (other than ReFS) how hard would it be for limetech to enable this thing to be configurable? run parity check automatically on reboot after dirty shutdown - YES/NO i am pretty sure there are other situations like when you have a failing drive that you dont want to do the parity check immediately especially when you have a dying drive which you do not want to overheat before you save the data etc. also i believe that the already existing checkbox to write parity corrections is much more dangerous to the user data than the checkbox to disable parity check on dirty reboot would be. this checkbox cannot be unchecked on my system (its always checked after every reboot) so if i have a failing data drive the parity will be overwritten with wrong data after a dirty reboot

you might be now the victim of the never ending parity check same as i am. discussed here if you dont have a 36 hour window for your parity check between CLEAN shutdowns you are screwed because Unraid will always do the new parity check until it is finished. Which is basically something you do want but not every day until you decide and make sure it can run it for the 36 hours uninterrupted

that is of course not true. The system does not know anything about your data or parity validity. It only guesses it and that is the problem you have not understood anything from this topic 1. i need it configurable not disabled 2. the data is still in tact 3. the OS does not premise nor guarantee you anything. And i have statistically and technically proven that my use case does not corrupt data while you have no argument against only theoretical BS about non-existent data protection.

i am talking about real data integrity, not about what the system can or cannot expect based on its own or any other technical limits but as you said it cannot know if it is true or false so its a most of the time wrong guess