dmesg output for the raid
call stack - 1
call stack - 2
This is on the latest version of TOS 6, using the 6.1.120+ kernel.
So, this situation is occurring during an active resync of a TRAID. From the processes that are spawned, it looks like the TRAID is a modified (or unmodified) raid 5? Let me know if this is the case.
It definitely affects raid 5, judging from the callstack, and it may affect any raid type with striping. It has happened multiple times over the past week with the exact same call-stack, so I believe this is reproducible. The times when the bug occurs seems to be random. I've had it happen in between two and ten hours. After which, the server begins to perform unresponsively, the SMB service no longer works and files do not appear to be able to be written or read from the share or the nginx proxy. The nginx and ssh services eventually become unresponsive too. Rebooting the server will cause (what I believe) this error to occur. After which, the server is only recoverable after power cycling the server physically. Performing a shutdown over ssh might work instead, I haven't attempted it. Also the resync loses its progress and is started immediately on boot, so it is a vicious cycle that one can enter.
The terramaster and smartctl report that all disks are good and I did not see any issues reported in dmesg in regards to physical hardware issues.
Here are a list of solutions I have to address this issue.
1.Freeze the resync process - using "mdadm --misc --action=frozen $RAIDDEVICE" (example: /dev/md0) will freeze the resync and the kernel panic will no longer occur. This has the consequence of your RAID being in a degraded state, so it is not a permanent solution. You can create a cron job or a scheduled task to run this every so often if you are worried that it might resume somehow (it WILL resume on shutdown/restart).
2. Wait to see if the Resync process completes - Basically, hope and pray that the issue doesn't occur.
Other than checking dmesg, you can also cat /proc/mdstat to see how far along your resync process is. After the process crashes, the number of synced blocks stops incrementing.3. Switch to RAID1 - Since disk mirroring doesn't have striping, it shouldn't be touched by this issue at all. I may need some help as to how one can accomplish this (either through mdadm commands, or if copying files to a different system, deleting the TRAID pool, and recreating as RAID1 will suffice). This would be, I believe, a permanent solution to the problem. It might depend on your storage limitations as to whether all data from the TRAID can be stored on RAID1.
Let me know if there are any other potential solutions!
