Problem with Orico Series - Unmounted Disk after a while

1. offizieller Beitrag

    Hi. How are you?


    I have a problem with a 5-bay HDD enclosure. More precisely with an Orico 9558RU3 (https://es.aliexpress.com/item…042311.0.0.557563c0CJoFA6).


    Disks are configured to be viewed individually. There is no raid configuration.


    After a while the disks are dismounted and not reassembled. Previously with OMV on a raspberry I had no problems.


    I also have a WD My Book Elementary external USB drive and it doesn't have any kind of problem.


    My desktop is:

    I5-9400

    H310 (https://www.gigabyte.com/ar/Mo…H310MSTX-HD3-CM-rev-10#ov)

    16GB sodimm (2 * 8gb)


    What could be the problem? TH!!!!!!


    I leave the logs:


    Hi,


    I have the exact same problem with the same Orico enclosure (model 9558RU3). I'm also running OMV on a RaspberryPi 4B.


    The problem occurs when the unit "wakes up" and the disks spin up. While that is happening, something seems to time out and the OS thinks it disappeared.

    I'm basing this logic on the following messages from the log:


    [ 2565.581087] sd 5:0:0:1: [sde] tag#0 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK

    and

    [ 2741.608777] usb 2-2: USB disconnect, device number 3


    I'm still digging to try to understand the cause. If someone else may have a clue, please pitch in.


    Thanks

    I am trying now to increase the value of the USB wait delay. Mine was 1 and I'm increasing it to 5 for now, will see what happens.


    Here's how you can see it:

    $ cat /sys/module/usb_storage/parameters/delay_use

    1


    Changing it requires root privileges.


    Problem is, I'm not always able to reproduce the issue, so it may take a while until I can say whether this works or not.

    I tried increasing the value in /sys/module/usb_storage/parameters/delay_use from 1 to 5 and 10 and that did not fix the problem.

    SInce that gets rewritten back to 1 at some point (probably at boot), I also tried to make the change permanent by creating a custom .config file in /etc/modprobe.d/ and writing options usb_storage delay_use=10 in it.


    Neither of these worked.

    In case others can help (ahem tkaiser ) : the Orico 9558RU3 unit is declared as having JMIcron JMS567 and either JMB394 or JMB575 controllers.


    From my diagnostics, the entire problem is caused by the fact that the unit has its own standby mode and goes to sleep after 10 min of inactivity, also putting the hard-disks to sleep. That happens irrespective of the APM settings of the hard drives themselves or hdparm. The 10 min interval seems to be flashed into the JMicron controller either by the Orico people or by JMicron themselves.


    After being put to sleep in this way, when disk access is required by the OS, the unit spins the disks up but somehow in a quirky way so that they appear missing or broken to the OS (see the attached dmesg_log.txt).

    Possibly as a result of that, the OS tries to reset them. Not succeeding that, the OS either disconnects them or "thinks" they are disconnected and subsequently unmounts the drives mapped to them. Interestingly enough, they still show up just fine in OMV's Storage -> Disks page, but when accessing the OMV Storage > File Systems page, that fails and a bunch of messages are thrown in the dmesg log.


    SO: it all starts by issuing a ls command. It will sit and wait for a few minutes, presumably waiting for the mounts to become available):

    pi@raspberrypi:~ $ ls -la /srv/dev-disk-by-label-DRC/ <- this hangs for a few minutes

    ls: cannot access '/srv/dev-disk-by-label-DRC/test': Input/output error

    total 24

    drwxrwsr-x 4 root users 4096 Aug 8 18:49 .

    drwxr-xr-x 14 root root 4096 Aug 10 14:16 ..

    drwxrwsr-x 2 root users 16384 Aug 8 18:12 lost+found

    d????????? ? ? ? ? ? test

    Weirldy, the last 4 lines of the output above seem to come from some cache, since clearly it's not coming from actually reading from the drive itself.


    Also a couple of times, when spinning up to service the "ls -la" command, only 4 of the 5 drives' leds lit up (?!)


    Then, when checking the OMV Storage > File Systems page, it fails:


    The resulting dmesg_log.txt is attached.


    Any help would be greatly appreciated.


    P.S. A similar issue seems to exist with JMicron's JMS578 chipset - see this Odroid topic. According to that topic, the Odroid folks managed to get JMicron to issue a patch for that chipset that fixed the issue. I could not find a similar patch for JMS567.

    Update: I checked the firmware version on my unit using the JMS578FwUpdate tool given by the Odroid folks here (step called "Example 6") and it turns out mine runs Bridge Firmware Version: v0.3.2.4. I have no idea whether it's the latest or not, but I can see that on the Orico downloads page there is an older version available for download (v0.3.2.3) here.

    Okay.


    I have 3 hdd.


    1- Ironwolf 4TB

    2- Ironwolf 3TB

    3- WD 3 TB (I don't remember the model)


    I did a raid 0 with the two 3TB disks and set the 4TB as "Large".


    Also set the raid to turn off after 10,000 minutes.


    Then I will tell you if the problem was solved.

    Zitat von sismondi

    both the 3559RU3 and 9558RU3 have raid capabilities. software should work on both

    I've mounted the unit on my Mac and it does recover from sleep. Also, I can connect to the disks in it very well.

    However, their software doesn't see the unit at all. I wonder if it's indeed 9558RU3 or something else.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden