cloaknsmoke

That's an interesting hypothesis. 3 of the 4 drives did come from a Windows PC previously and therefore have had multiple filesystems over the years. However, 1 of them has only been used on my Unraid computer. It was a parity drive first. I may have formatted it as ZFS at some point before deciding that it was screwing with the performance and formatting to XFS. I'll try this out tomorrow once the parity sync is done.

I wanted to remove a 3 TB drive from my array. I moved all the data off and verified with Krusader that there was nothing left in the root. I wanted to use the script that zeros a drive while maintaining parity, but it failed. It took only a few seconds and the drive page then said it only had 16 gb of space. Obviously, this didn't zero anything. At this point, I figured I would have to go with the second way of making a new config and re-syncing parity. All the drives up to this point are working fine and recognized in the system as they should be. I go to create a new config while saving the assignments then remove the 3 tb drive that now has nothing on it. Since it's a new config, all the drives say auto filesystem before the array comes online. This is normal I think. So I start up the array expecting to have to let it rebuild parity and such which takes about 24 hours as my largest drive is 10tb. I am, however, greeted with only 4 out of 8 drives (and the cache pool) recognized as mountable partitions. The rest say auto and unrecognized or unmountable partition. I immediately start sweating at this point and stop the array as I don't want the system to be reading/writing from it in this state until I understand more of what's going on. I figure that the worst case is I can use some file recovery on my PC to get the files off which would be an incredibly lengthy process since it's like 11 tb of data across all drives. Since parity isn't valid anyway, I could use my parity drive to hold the data, reformat, the recopy it without protection before rebuilding parity. But first I figured I would try some easier solutions. My main computer is a Windows machine which obviously doesn't recognize XFS. First I tried Linux file systems for Windows by Paragon software. It didn't recognize any drive that was already recognized by unraid nor any of the ones that weren't. Second was Hetmann Partition Recovery which immediately recognized everything. So this told me the drives/file systems must be at least mostly intact. I quickly downloaded ubuntu and stuck it in a vm then passed through one of the drives that Unraid didn't recognize, and it had no problem mounting it. I ran xfs_repair on one of the drives just to see if there was some file system corruption causing the issue, but it still isn't recognized by Unraid despite the local xfs_repair tool understanding the drives (or at least the one drive I'm using for testing). Unnassigned Devices also has mount greyed out. Anyone have any other ideas? Preferably ones that don't involve me copying the data from the drives, reformatting them, the copying the data back since that would be unprotected. EDIT: So I realized I could just force the system to look at the drives as xfs when the array was unmounted. I'm not sure why it didn't just recognize this fact for all drives immediately without me having to do this, but it did ultimately work. Or at least, it's currently syncing parity and in 24 hours it will hopefully be fine. What I did in case anyone finds this threat later, was just set everything to xfs from auto then started in maintenance. Then I ran the xfs_check from each disk page to confirm the system didn't think there were any file system corruption (there wasn't). Then when I started the array... everything broke for an unrelated reason. But when I fixed that problem, it all worked fine. The unrelated issue had to do with one of my cache drives that randomly disconnected for some reason which caused a lot of kernel errors and the system freaked out and crashed.

I reformatted all the array drives to XFS instead, and that appears to have fixed the issues based on some limited testing. Thank you for your help.

So it's better to have array drives formatted in xfs or btrfs?

I recently decided to switch from Windows to Unraid for a number of reasons, but mostly because it seemed like a simpler method of managing/protecting drives. I have several drives in the array with parity fully calculated on the single parity drive. I have reconstructive writes turned on and the md_num_stripes parameter set to 4096 because I saw some posts saying increasing it could make things faster if you have more memory (I have 32gb). All drives are formatted with ZFS. There is also a pool of SSDs I intend to use for cache formatted with BTRFS, but I currently have all shares writing directly to the array since I am having to move a lot of data right now to put everything on the array initially. Due to size disparity, only 1 drive is having anything written to it right now. This will presumably change as more is written to the array, but it's prioritizing the 8tb drive at the beginning. I have tried 3 different ways of writing, and all display this behavior to some extent. Copying over the network, it will actually time out regularly. I have also used Krusader and mc over ssh. mc definitely performs the best with it usually going several gb before dropping down to 0 for a bit and then resuming. Krusader will say Stalled as the copy status when this happens and it generally persists for longer than with mc. What seems to be happening from monitoring the array's disk activity is that everything is writing just fine at full speed for a while. It properly reads from the disks that it isn't writing to and writes to the parity/data disks at the appropriate speed. Then it just falls off. It isn't a gradual decline or anything like that. It just writes appropriately for a while then stops for a while. I got a plugin to show me some graphs of activity over time, and during the "no activity" time, there appears for be a very small amount of activity on the array of between 5-20mbps while the transfer itself will be stalled out. During this stall time, there will be 2 and sometimes 3 random cpu cores at 100% utilization with the rest at minimal usage. This is compared to during peak transfer where no single core is stuck at 100% with the average of all 12 threads sitting around 30-40%. The further into a large job I get, the more frequently it will happen. The memory is overclocked, but it's still under the spec of the memory (like overclocked from the default 2133mhz). I also ran memtest for about a day continuously before starting this whole process. The CPU is a Ryzen 5600X and I put it in eco mode in the bios. pterbomb-misc-diagnostics-20241002-1619.zip