chris206

Parity check finished without errors. Everything's all good it seems.

Will do. It's scheduled to start tomorrow and is set up to increment, so I'll report back in a few days with results.

Done. tower-diagnostics-20260110-2152.zip

As the title states, the drives in my DAS didn't appear upon booting my server, because I failed to plug in the external cables correctly. I shutdown my server and the das, fully seated the cables and rebooted. All of my DAS drives show up now and short SMART tests of my two parity drives and disk 16 was completed without issues. These three drives are a part of my DAS along with the 4 12TB unassigned drives. The question I have is, should I proceed with caution still and start my array in maintenance mode to perform further checks? If so, what would those be? I'm due for a quarterly parity check that I've postponed for a week due to swapping hardware in the server. tower-syslog-20260111-0258.zip tower-diagnostics-20260110-2058.zip

To elaborate a bit further. My drives are actually connected to a SAS expander card, that is then plugged into the SAS raid controller. So perhaps the SAS expander had temp issues upon spinup? I need to recheck my drive positions in my tower, but based on previous notes it seems that the drive errors were spread across three different power splitters each on their own individual SATA power cable back to the PSU. Edit: Also, I should add, the 14TB drives and the 4 in unassigned devices are plugged directly into the RAID card through two of the external ports in a DAS.

I believe it should be in IT mode? I would not be surprised if it's setup wrong, I'm certainly an amateur.

Done. I often forget to include that one, thanks. tower-diagnostics-20251221-1506.zip

I am using power splitters. There should be a max of five drives on each SATA power cable if I'm recalling correctly. The SAS card itself has a noctua 40mm fan attached to it that is constantly spinning at ~3k rpm. I could certainly open up the back of my tower and trace each drive back to their respective power cable.

Today I decided to start using a different approach to managing my drives in my array. I thought I'd start spinning them down after an hour of no usage. This seemed reasonable until I ran into an issue when I opened windows explorer on my PC to access a local file which has a share folder from my array mapped as a network drive. I traced my array drives all spinning up to the opening of windows explorer. This led to five of my drives having four read errors each, which I assume was related to the drives not being fully spun up when explorer tried to access some data on them. My filesystem seemed to have some issues as I couldn't see any of the folders/files on the mapped network drive. I went ahead and stopped my array and started it back up, which unRaid reported as error free and the errors disappeared on the main tab in the GUI. I was also able to browse the folders properly after doing this. So, my primary question is, how can I prevent windows explorer from doing this in the future? I removed a network folder that had been pinned automatically to quick access by windows, but there's also a few files in the history of explorer too. Should I turn off indexing for the mapped network drive? Also, should I be concerned about those five drives throwing four read errors each and the filesystem not being accessible until I stopped and started it back up? tower-syslog-20251221-0439.zip

Finally reran xfs_repair through the CLI. The GUI for check filesystem doesn't seem like it'll refresh itself after taking the array out of maintenance mode. Anyways, I uploaded the output from the CLI. Seems like it zeroed the log and mentioned moving files to the lost + found, but I didn't see that folder on the disk after starting the array. Everything still checks out okay and that previous warning I was worried about is no longer there. Not entirely sure what caused the issue with reporting the remaining freespace, but I've got a new drive in my server, so hopefully it won't happen again. Thanks for all of the help. xfs_repair_log_20250824.txt

Alright, should I run that through the terminal as well or is the GUI fine? I don't remember having the ability to change flags in the check filesystem section for the disk's page.

Before this reply, I had gone ahead and started the array with a new disk, which is in the process of being cleared. Prior to that, I had checked several of the files on the disk and everything seemed okay. In addition, I managed to free up ~280 GBs of space by cleaning up some folders. If still recommended I can run that command after the disk clear is done tomorrow. Question though, I can't seem to find documentation on what -v flag is for xfs_repair, what's it do?

Hmm alright, I do get this message in the syslog, "XFS (md15p1): Per-AG reservation for AG 9 failed. Filesystem may run out of space." I'm guessing to resolve that I should move some files from that disk to another using krusader in order to free up space?

I also checked the filesystem on the drive and it seems to be back up without any lost+found files, so I'm not entirely sure what happened. Yesterday prior to the filesystem going down on the drive, I had roughly 1.8 TB of space left on it, so unless it stopped reporting the free space left accurately, I'm not sure how it managed to fill all the way up.

So, I stopped the array in maintenance mode and restarted the array normally. The disk mounted but said it was at almost 100% utilization. If I go back to the disk to look at check filesystem status, the repair hasn't reset at all and still has the same option before about zeroing the log. Any tips would be appreciated. tower-syslog-20250823-0232.zip