Assistance needed and appreciated - not sure how to get this drive back online.  Based on reading other posts, I have tried to move this drive to another slot in my DAS enclosure but the result is the same. 

 

Starting to believe that Unraid is a little too finicky and sensitive to remain stable.  I have spent months trying to get a stable system to support my media and Plex server and yet another disabled disk that is one of three brand new drives.  I gave a pass to Unraid for the 5 older working disks being disabled in 2 different enclosures and direct SATA connections.  Am I simply wrong with the frustration?

tower-diagnostics-20230616-1910.zip

Diags are after rebooting, so we cannot see what happened, did you assign old disk1 to disk3? You cannot do that to replace the disk, if you did, unassign disk3, start array and post new diags.

Hi Jorge - I did select the disk on disk3 just to see what the system would say but never started the array.  I have everything back to the original slots, started, and exported new diags.

 

These were the errors flooding the syslogs prior to reboot and trying a different bay in the DAS to rule out connectivity.

Jun 15 18:25:38 Tower kernel: BTRFS error (device loop2: state EA): bdev /dev/loop2 errs: wr 13, rd 5825102, flush 0, corrupt 0, gen 0

Jun 15 18:25:38 Tower kernel: I/O error, dev loop2, sector 81472 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 0

Jun 15 18:25:38 Tower kernel: BTRFS error (device loop2: state EA): bdev /dev/loop2 errs: wr 13, rd 5825103, flush 0, corrupt 0, gen 0

Jun 15 18:25:38 Tower kernel: I/O error, dev loop2, sector 605760 op 0x0:(READ) flags 0x1000 phys_seg 4 prio class 0

Jun 15 18:25:38 Tower kernel: BTRFS error (device loop2: state EA): bdev /dev/loop2 errs: wr 13, rd 5825104, flush 0, corrupt 0, gen 0

tower-diagnostics-20230617-1556.zip

Emulated disk is mounting, assuming contents look correct you can rebuild on top:

 

https://docs.unraid.net/unraid-os/manual/storage-management#rebuilding-a-drive-onto-itself

 

13 hours ago, schollingsworth said:

These were the errors flooding the syslogs prior to reboot and trying a different bay in the DAS to rule out connectivity.

Those are about the docker image, but would need the full syslog for context.

Rebuild in process - will know in a 6ish hours if we get back operational. thank you

 

Questions:

In the future, when a drive gets disabled or shows failures, the key is to generate a diag before rebooting if we want to know what happened - correct?

Is it best practice to start docker containers manually?

Are there any other best practices to keep the system healthy?

Basically how can I avoid or make tuning configurations to lower the number of times the system disables disks?

28 minutes ago, schollingsworth said:

In the future, when a drive gets disabled or shows failures, the key is to generate a diag before rebooting if we want to know what happened - correct?

Yes.

 

28 minutes ago, schollingsworth said:

Is it best practice to start docker containers manually?

It should be fine to start them automatically.