Raspberry Pi 4, Orico 4 bay external USB 3 enclosure, disk unmounting, verify my solution

Hello,

I'd like to ask you for help with my RPI4 OMV 6 setup. I hope it's not too long.

TL;DR; I'd like to confirm, that my solution using mount -a in a cron job every few minutes is a good idea for dismounting discs in Orico enclosure.

Some context:

I have freshly installed OMV 6 using the script from https://github.com/OpenMediaVa…-Developers/installScript.

I'm using recommended official Raspbian (11 without desktop).

I have Orico 4 bay USB 3 enclosure (with power supply) connected directly / or indirectly through hub to RPi 4 USB 3 port.

Inside I have 3 disks of sizes 1TB - 4TB. I use EXT4 on all of them.

No raid.

Enclosure: https://www.amazon.com/ORICO-E…age-9548RU3/dp/B07XL1QQY9

All installation, setup etc. works flawlessly, no issues on that front.

Issue:

I see the disks, can use them with shared folders, I can access them over network and all works well and fast.

After some time of inactivity (it seems), the disks unmount or something... in UI they are marked as "unmounted" and in dmesg/log there are error messages about accessing them (see below).

What I've found so far

I'm already searching for solution for few months and read many answers in this and other forums. I'll add links to the bottom of this post for completeness.

Seems like it's an issue of Orico enclosure that will simply put disks to sleep and spin them down after some period that can't be setup in its configuration software (on Windows). Sometimes OMV/Linux works fine with that, on usage, it wakes up the disks, spins them up and I can use them. Sometimes it just doesn't and all fails.

It sometimes happens after few minutes, sometimes after many hours.

What seems to help is using mount -a as suggested in another thread here (see links below).

By that I mean when the issue appears, I need to wait for enclosure to "get ready", system needs to spit all the errors in log and after that, running mount -a simply restores them and all works. For now I have it as a cron job running every 5 minutes. May change that to 1 minute later.

What didn't help (for context)

• I've tried configuring OMV's Advanced Power Management for disks in various ways but it seems irrelevant; now I have it turned off
• I've tried config tool from Orico (Windows) and set various combinations of "sleep" intervals (0, 1000000, etc...)
• I've experimented with some tips about mounting options in fstab and quirks etc.
• I've tested multiple setups regarding physical power supply (RPi its own official supply, direct and indirect USB connection with USB 2 and 3 hubs etc.)
• I've tried running with combinations of disks (only one etc.)
• I've originally started with same enclosure, but RPi 2, USB 2 and OMV 5; same issue, probably even more frequent (subjectively)
• I've experimented with some USB configuration (autosuspend, delay_use and whatnot)

What I'm asking for

I'd like to ask if this solution is "safe" and really best one I can have?

Is there any risk to my disks, data or something?

Is there any alternative? Apart from buying other/better enclosure? (I have seen such advices. Thanks. But that's not the question. Some could suggest buying Synology then).

It really feels like a dangerous hack, ignoring all those errors.

I'm really grateful for all the work you put in this and the support, the install script is really awesome, I really hope I'll be able to use this setup/software and maybe even help somehow.

Links

- https://www.reddit.com/r/OpenM…periodically_dismounting/ (general talk, mostly about power supply)

- https://wiki.omv-extras.org/do…ide#initial_configuration (installation I used)

- https://forums.raspberrypi.com…a8c7d50251914e3554bd17b70 (USB issues on RPI4)

- https://forums.raspberrypi.com/viewtopic.php?f=28&t=245931 (quirks and drives on usb RPI4 and other fun)

- Auto mount USB drive when reconnected (very similar mounting issue)

- https://forums.raspberrypi.com…a12875667b49afdfd63b8b716 (RPI 4 external disk and mounting)

- Problem with Orico Series - Unmounted Disk after a while (the closest post of all forums I've found, there are the error messages I see in logs; exactly the same ones in dmesg)

Thank you both kindly for quick answers!

I'll give it a shot.

But may I ask, using touch will wake up the enclosure and also spin up the disks, won't it? I tried and it does.

I'm no HDD expert, but I was hoping to keep the disks spun down to extend their lifetime and save energy and noise.

Is that wrong expectation? Should I just keep them spinning all the time?

Or even with touch I could use advanced power settings to spin them down or something?

My use-case is simple home long-term storage, not very often needed, say once a day max, so 24/7 spinning seems inefficient.

Thanks again!

Alright, fair enough, thanks. I'll experiment with that.

Thanks for suggestion, yes, I considered this option too.

But I have Windoze users mostly who would struggle with that. I mean, even running a prepared script/"icon" before accessing the shares from the desktop would be pain for them. Still a kind of automation I can try, some PowerShell that will wake the disks up and then lets user open the folder.

One benefit of my current mount -a solution seems to be, that it doesn't spin the disks up. At least not every time.

I had the disks spun down for good 8 hours, while cron was kicking in every 5 mins. And when I tried to access them, it failed for the first time, they spin up and once cron runs "mount -a" it all works.

So my question is in what "mount -a" every minute could be worse than "touch"? Sorry for my ignorance in this, I really don't know.

I can imagine it generates tons of error logs whenever this wakeup happens. But apart from that, it seems ideal to me.

I will accept even "feels like a bad idea" answer, since it does to me as well :))

Thanks both again

Yep, like I said, looking at this for months already.

I think mount works because it will see there are disks expected in fstab and they are ready but not mounted. Enclosure must be ready by that time.

I will try some more and report back here.

I guess we can consider this closed.

I just wanted to report back after a while. Didn't have that much time for it recently.

But I'm experimenting with device timeout settings and it seems to be affecting it a bit at least.

It's not a final solution, still sometimes the device needs to wait for the whole timeout, then throw all the errors mentioned above and then "sudo mount -a" will fix it again. But it's happening less often, seems. I'll experiment more with that and report here again.

Here's what I have so far:

#!/bin/sh
# TIMEOUT=30 # original timeout; 10 original eh_timeout
TIMEOUT=300
for f in /sys/block/sd?/device/timeout; do
    echo "Changing ${f} timeout to ${TIMEOUT}"
    echo $TIMEOUT >"$f"
done
for f in /sys/block/sd?/device/eh_timeout; do
    echo "Changing ${f} eh_timeout to ${TIMEOUT}"
    echo $TIMEOUT >"$f"
done

It's based on following links:

https://raid.wiki.kernel.org/index.php/Timeout_Mismatch

https://unix.stackexchange.com…isconnect-and-data-corrup

https://unix.stackexchange.com…nux-attempting-task-abort

What I plan next is to play with more values of these timeouts and then try to find a way to capture the event when the timeout is happening and immediately re-mount given device. Seems to me that would be relatively clean solution. It's what I actually expected OMV to try after some time, to re-mount the known drives.

Anyway, enough spam, I'll report back later.

Cya

Hello, reporting after some time with a short update.

Setting the timeouts (previous post) higher changed the behavior, the connecting client was waiting longer and it seemed sometimes it helped. But I think it was just a feeling, overall the issue remains the same.

Lowering the timeouts made the "unmount" of disks a little faster, but not as fast as I though, like ~5s. So not a solution too.

Having a task running "mount -a" every minute works quite reliably, but sometimes it's still slow.

My next attempt is to find some system event I could follow up with action to remount the drives.

Another one later will be to try waking up disks in some periods, say every 8 hours, just for a short time and spin them down immediately. So far it seems that it's enough to keep the unit "informed" that it's needed and it will always properly work. Imo that would be the best solution, to have the disks spin ~3 times a day for a minute, spin them down with "hdparm" but at all other times it would work normally.

Will keep you posted.

Thx!

Hi all,

after all the struggle I report again with final failure.

I tried waking up the unit in intervals, tried to setup some kernel error watch / handling etc... with no success at all.

My final solution is simple, for the data that I want right away I simply connected a separate USB external drive that just works flawlessly, first time. No issue since then at all.

That Orico unit is really problematic, but for my needs of long-term storage it's fine. When I need it, I can give it some time to catchup.

So my final solution is running "sudo mount -a" every 3 minutes. It's mostly harmless, seems. No logs produced, nothing happening when the unit is sleeping. When I need to use the data there, I try to access it. It sometimes works, sometimes fails. When it fails, in under ~3 minutes it's back up and I can work. But it does produce "million" error logs and doesn't seem healthy for any serious usage (e.g. work environment).

If anyone would like to use it more actively, as suggested by others above, keeping the unit awake all the time with simply "touch"-ing some file would work. But it would keep the disks spinning 24/7.

Sorry guys I don't have better news, but I also don't have enough time to invest in some kernel debugging. The timeouts solution above may be near, idk.

Thanks for all your support!