howlyeye

Hi Johnnie, I take it that the re-enabling of the parity disk will be the same procedure as re-enabling disk1? Unfortunately we could not access the server in any way to perform a diagnostics test before rebooting. Once we have done the rebuild, we will check all of the disk connections and ensure that the HBA is seated properly to rule these out. It seems like a series of weird but non-serious problems, and I hope that this turns out to be the case. I will update this post with any more information should something new come up. Best

Hello, Just this morning after doing some tests with a version of Handbrake, several concerning things happened. The first, is we got an error about our cache drives being overheated. These are both Intel 660 NVME drives, and should be running hotter, so this is not particularly concerning, but what followed was. After doing some work converting videos in an internal build of Handbrake (something pulled off of community applications), two of our drives were disabled. These were Disk1 and the first Parity disk. The system norunevillage-diagnostics-20200122-1114.zipwas inaccessible through the GUI or the WebUI. We were forced to reboot. After rebooting, we followed the instructions to repair the disks by stopping the array, removing the disk from the array, restarting, stopping again, and re-adding the disk to the array. A disk repair began as expected. We only noticed at this point that the Parity disk (the first of two) was now disabled, with the hover-text showing "Click to spin down disk." We did not do this. It seems that all of the data is still available, both on the cache drive used to convert videos, and the disk1 (which should be the only disk with data on it, as this is how we configured the Rsync from our old server). I can watch all of the videos that had been copied up until that point, with the most recent one being able to be viewed in its entirety. It does not seem that there is any corrupted data, and we haven't lost any data to the best of our knowledge, but the errors appearing while not experiencing any data loss symptoms is strange. Attached is the most recent Diagnostics. I have heard that it could be a seating issue with the HBA in the server, but I do not want to check this until the data has been rebuilt (I do not know if it's actually rebuilding anything, as all of the files are present, but I am too scared to interrupt it). I appreciate any and all input! Best

Hi, Apologies for late posts. I believe you were correct, and upon checking which shares were given direct access to the cache, the writes and reads were what we expected. I will have to keep this in mind in the future. Best

Both FastTest and SuperFastTest were the ones we tried, as we tried to create a new share to see if any settings / files were not sent there properly.

Hello, We are having difficulty figuring out why the reads to a share that should be only to our cache drives are starting off so quickly and then slowing down quite dramatically. Attached is the diagnostic .zip. Basically, working with a 10 GB file, we can write to this cache (which is set to Only, which I take means that the share is only saved on the cache drive, for testing purposes). The upload gets very close to 1 GB/s. Immediately following this, the file is copied BACK off of the server (which should still be on cache) and it starts at about 1 GB/s but slows to nearly 250 MB/s at the halfway point in the transfer. I've tried enabling write cache on all of the drives, and noticed that the first drive in our array is getting reads while this is happening. Is there a way to ensure that writes stay on the cache drive (which is a pool of 2 M.2 SSDs) until dumped into the array? This should not be put into the array so soon (several seconds) after writing to the cache drive. I hope that I've made clear what I would like to happen and the problems I am facing. Thank you! norunevillage-diagnostics-20200118-1056.zip