[Solved] Acasis scsi enclosure and raid1 mount dev/md0 crashes freezes

[seahorse41]

I have a Acasis EC-7352 set to JBOD mode (Just Bunch Of Disks) so not trying to do hardware raid. (that's another story I abandoned)
I have 2 identical WD Ultrastar HUS726T6TALE 6TB hard drives.
I have (had) a working raid-1 that mounts and runs ok for a few weeks, seeming like earlier problems were in the past.

Code: Select all

$ fdisk -l
Disk /dev/sdc: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: EC-73520        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: BF5C5010-71BF-4FE6-852F-1E01DD90C1E5

Device     Start         End     Sectors  Size Type
/dev/sdc1   2048 11721043967 11721041920  5.5T Linux filesystem

Disk /dev/sdd: 5.46 TiB, 6001175126016 bytes, 11721045168 sectors
Disk model: EC-73521        
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: CC9B7C53-E025-41EC-8BAB-877D884E190A

Device     Start         End     Sectors  Size Type
/dev/sdd1   2048 11721043967 11721041920  5.5T Linux filesystem

$ sudo lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdc       8:32   0   5.5T  0 disk  
└─sdc1    8:33   0   5.5T  0 part  
  └─md0   9:0    0   5.5T  0 raid1 /mnt/Acasis_RAID1_6Tb
sdd       8:48   0   5.5T  0 disk  
└─sdd1    8:49   0   5.5T  0 part  
  └─md0   9:0    0   5.5T  0 raid1 /mnt/Acasis_RAID1_6Tb

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdc1[0] sdd1[1]
      5860388864 blocks super 1.2 [2/2] [UU]
      bitmap: 0/44 pages [0KB], 65536KB chunk

unused devices: <none>

$ sudo mdadm -D /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sat Jan 27 12:07:27 2024
        Raid Level : raid1
        Array Size : 5860388864 (5588.90 GiB 6001.04 GB)
     Used Dev Size : 5860388864 (5588.90 GiB 6001.04 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Jan 29 18:26:15 2024
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : roxy10-debian11-x64:0  (local to host roxy10-debian11-x64)
              UUID : 1e3f7f7e:23a5b75f:6f76abf5:88f5e704
            Events : 21674

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1

$ df
/dev/md0       5813107304 2543033168 2977054696  47% /mnt/Acasis_RAID1_6Tb

$ lsusb
Bus 003 Device 003: ID 214b:7250 Huasheng Electronics USB2.0 HUB
Bus 003 Device 002: ID 214b:7250 Huasheng Electronics USB2.0 HUB

$ cat /etc/debian_version 
11.8

Today I powered it up, and tried to mount it, but it failed.
After 5 minutes the computer froze up, no screen updates, no keyboard. Frozen.

Rebooted, and looked at /var/log/messages
Lots of errors, several call-Trace events.
I repeated the sequence and confirmed it is repeatable.

Code: Select all

$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : inactive sdc1[0](S) sdd1[1](S)
      11720777728 blocks super 1.2
       
unused devices: <none>

$ sudo mount /mnt/Acasis_RAID1_6Tb/
mount: /mnt/Acasis_RAID1_6Tb: can't read superblock on /dev/md0.

I have clipped the 5 minutes of /var/log/messages showing the attempts to mount the drives, the multiple Call-Trace events, right up to the system freezing. It is long and repetitive, but contains useful back trace I hope. See zip file.

Besides saying the enclosure firmware is garbage, despite being advertised as being compatible with linux, can anyone say why it crashes so badly? and anything I should try before tearing it apart and trying other solutions to get my data rescued?

Thanks

[Aki]

Hello,

Errors reported in the logs are low level errors (sata errors).

You may move the disks to a working different enclosure to verify if they works or if it is the Acasis enclosure at fault.

[seahorse41]

Errors reported in the logs are low level errors (sata errors).

Okay, that is useful to know.
Onward to find a replacement enclosure...

For anyone else finding this thread by searching for Acasis... My experience with it includes:
Reasons to doubt the enclosure and firmware:
1. hardware raid mode did go to sleep at 10 min. which apparently was not able to finish the duplication. Keeps going to sleep at exactly 10 min. Chinese support would not confirm it has been certified to work with ext filesystem. Keeps wanting videos showing problem.
2. No way to see status of drives, dependent on led turning red.
3. Always copies from small to larger or same size drive, but newer replacement drives tend to be smaller.
I switched to software raid-1 as md0:
4. First 10 min. sleep, did not wake correctly, only mounted 1 of the 2 drives. Noticed 1 hour later fan and leds were not on, so temperature rose to 62C.
By writing to only one drive, required a resync when md0 was mounted next time. Took a few hours, but not the full 9.
Then 2 weeks without problems.
5. Lots of activity that has nothing to do with access from computer. even as JBOD mode. Is unsettling, diminishes trust.
May be the cause of this latest loss, unnecessary writing after being unmounted.

[seahorse41]

Ugreen 50423 works. Hard drives and data are okay.

One of my questions seems unanswered, why did those errors crash the operating system?
Shouldn't the OS be uncrashable?

[Aki]

Ugreen 50423 works. Hard drives and data are okay.

I'm glad you sorted it out. :)

Please, mark the discussion as "solved" manually adding the text tag "[Solved]" at the beginning of the subject of the first message (after other tags, if any); for example: [Solved] Acasis scsi enclosure and raid1 mount dev/md0 crashes freezes

One of my questions seems unanswered, why did those errors crash the operating system?
Shouldn't the OS be uncrashable?

Did these disks host the operating system? Operating system components need to be continuously read from them.

[seahorse41]

Please, mark the discussion as "solved"

Did these disks host the operating system? Operating system components need to be continuously read from them.

I'll be happy to mark it solved once my unanswered question is all good.
We have 2 things outstanding, the hard crash of the OS, and this last question:
No this was not hosting anything. Just extra data storage, primarily backups.
Thanks

[CwF]

We have 2 things outstanding, the hard crash of the OS, and this last question:
No this was not hosting anything. Just extra data storage, primarily backups.

As far as you explained we don't know for sure the OS was actually dead.
If you don't have serial or ssh type access you wouldn't know, or be able to ascertain, whether the DE or session has died or if there is a deadlock.
How this works out does depend on hardware choices. I don't have anything that won't beep on error as seen by the motherboards hardware watchdog. I've had single beep and an automatic reboot, to cascading failures where I could try to stay ahead until the last beep.
The two major error categories are storage or video controllers. I've had gpu lock issues before that are in that cascade type and often have active ssh access for minutes. I've seen storage controllers accessing discrete devices as a virtual machine all supposedly isolated from the host, take down the host. Deep hardware bugs are hard to find. As far as I can tell, those two things (and fancy net cards) all have bios hooks that can spit out garbage and kill the system.
Whenever a piece of hardware is coincident with failure we should either diagnose it or throw it away, neither include 'using' it.

[seahorse41]

Right, I didn't try ssh from another computer on the network. Oh well...
All I know is keyboard and video were frozen.