Hello everyone,

 

I'm relatively new to Unraid. I was thrilled to finally build my own Unraid server a few months ago, but since then I ran into the same exact issue 3 times within a couple of short months and I must say it's starting to ruin what otherwise would have been a great experience with Unraid.

 

My configuration:

UNRAID version 6.7.2
ASUS M5A78L-M Plus/USB3
AMD FX 8300 (8-core @3300MHz)
32GB DDR3 (4x8GB 1600MHz)

------------------------------------------------------------------------------------------------

Cache: 480GB PNY CS900 SATA SSD
Boot: 16GB Verbatim Store’N’Go USB2.0
Parity: N/A

------------------------------------------------------------------------------------------------

Dell PERC H310 SAS Controller 0HV52W / LSI 9211-8i (IT-mode)

------------------------------------------------------------------------------------------------

Disk 1: 8TB Seagate ST8000DM004-2CX188   (sdb)
Disk 2: 8TB WD WDC_WD80EZAZ-11TDBA0   (sde)
Disk 3: 8TB Seagate ST8000DM004-2CX188   (sdc)
Disk 4: 8TB Seagate ST8000DM004-2CX188   (sdd)
Disk 5: 8TB Seagate ST8000DM004-2CX188   (sdf)
Disk 6: 8TB Seagate ST8000DM004-2CX188   (sdh)
Disk 7: 8TB Seagate ST8000DM004-2CX188   (sdi)
Disk 8: 8TB WD WDC_WD80EMAZ-00WJTA0  (sdg)

------------------------------------------------------------------------------------------------

 

• The array contains 53TB of data (94.6% utilization), mostly video files (1-2GB each) along with a few metadata files (txt, jpg, etc) accompanying each video.
• The data is spread among 14 shares, and accessed by 2 users “READONLY” and “READWRITE” (names reflect level of access the users have to the shares).
• 3 docker containers run 24/7 (DelugeVPN, Plex, PiHole), and a couple of containers and VMs which I only spin-up to perform specific tasks (Dolphin, Windows VMs)
• All containers are residing on the 480GB cache drive
• DelugeVPN reads/writes to a “downloads” share on the cache drive, this share’s “use cache disk” is set to “prefer”
• Plex reads (doesn’t write) from 2 specific shares (which happen to hold most of the data on the array)
• Most writes to the array are either manual file manipulation (from a Windows client), or the Unraid “mover” moving files nightly from the 480GB cache to the array.
• The data is non-critical, I would still like to minimize any data loss, but I won’t be losing too much sleep if some of it has got to go.

 

 

The issue:

• I noticed that a lot of my shares (8 out of the 14) have disappeared (from the “SHARES” tab in Unraid), and (of course) are no longer reachable from client devices.
• I stop the array, then started it in “Maintenance Mode”, I notice that Disk 1 (sdb) of the array is flagged as “Unmountable: No file system”
• From the terminal, I ran the following command:

               xfs_repair -L /dev/sdb

• Once the command finishes running, I stop the array, then start it (normal strart, not maintenance mode), it starts successfully and my shares are back.
• I browse the array contents (from Windows client) and find a bunch of folders in the “lost+found” directory, containing files that seem to have been slavaged from the corrupted disk. I manually move the files to the correct folders/shares, and supposedly everything is back to normal

 

As I mentioned earlier, this corruption issue occurred 3 times in 3 months (the server was build recently, although the array drives are a mix of brand-new and somewhat used shucked drives (oldest drive is less than 2 years old), the issue always happened on the exact same disk (Disk 1, sdb, an 8TB Seagate I shucked from a 1 year-old Seagate Backup Plus Hub 8TB).

 

So, what do you guys think? Is this simply a case of a specific disk in the array being defective?
If that’s the case then I don’t mind replacing it with a new one, but before I go ahead I wanted to pick your brains and check perhaps I’m missing something.

1 hour ago, bams said:

xfs_repair -L /dev/sdb

This command is incorrect. In fact, I assume it is a typo, since you can't repair the disk (sdb), you can only repair the filesytem on a specific partition (sdb1). And, you should never attempt to repair a sdX device in the parity array anyway. You must only repair the md# device. Repairing sdX in the parity array invalidates parity.

 

There is no need to go to the command line for this, you can do it from the webUI by simply clicking on the disk to get to its page. And if you do it in the webUI, then you won't get the command wrong.

 

1 hour ago, bams said:

supposedly everything is back to normal

Except you have invalidated parity.

 

Since your disks are so full, my guess is you are corrupting them by trying to write more than they will hold. Do you have Minimum Free set for any of your user shares?

 

Go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post.