What do you mean by USB hard drive enclosures? Are you limiting the RAID (8 bay) throughput by a single USB line?! That's like towing a ferrari with a bicycle.
I have one enclosure plugged into a USB 3.0 line, another plugged into a "super speed" line, and one plugged into a Thunderbolt line (shared with my 10GbE Thunderbolt card with a 2x20 gigabit splitter).
This was deliberate, each is actually on a separate USB controller. Assuming I'm bottlenecked by the slowest, I'm limited to 5 gigabits per RAID, but for spinners that's really not that bad.
ETA: It's just a soft RAID with ZFS, I set up each 8-bay enclosure with its own RAIDZ2, and then glued all three together into one big pool mounted at `/tank`. I had to do a bit of systemd chicanery with NixOS to make sure it mounted after the USB stuff started, but that was like ten lines of config I do exactly once, so it wasn't a big deal.
Have you researched the USB-SATA bridge chips in the enclosures? Reliability of those chips/drivers on Linux used to be very questionable a few years ago when I looked around. Not sure if the situation has improved recently given the popularity of NAS devices.
From my research a couple years ago it seemed like most issues involved feeding a bridge into a port multiplier, so I got a multi drive enclosure with no multipliers. I've had no problems so far even with a disk dying in it.
Though even flaky adapters just tend to lock up, I think.
Ah yes! Port multiplier is usually the source of most evils (after flaky bridge chips). Unfortunately enclosure makers seldom reveal the internal topology and usually only test again Windows, and Linux kernel has a long blacklist of bad bridge chips…
that's a benefit of zfs, it doesn't trust the drives actually wrote the data to the drives, the so called RAID write hole, since most RAID doesn't actually do that checking and drives don't have the per block checksums in a long time. It checksums to ensure.
The issue with flaky bridge chips wasn't usually about data integrity——it works fine most of the time, i.e. data written got read back correctly.
But often after extensive use, `dmesg` would complain about problems when talking to the drives, e.g. drive not responding or other strange error messages (forgot the exact text but very irritating and google-fu didn't help). There were also problems with SMART commands passthrough and drive power management e.g. sleep/standby adjustment which wasn't reliable when talking via bridge chips.
I use only disks directly connected to SATA controllers afterwards and no such issues ever happened again.
So each enclosure hosts its own RAIDZ2. Have you tested if it can survive loss of USB connectivity? It can happen because of cable damage or movement, and also because of any failure in the enclosure's electronics.
This reminds me of a trivial browser notepad I hacked together a while back. Have been using this and has been indispensable - quickly open and jot down some notes. Has syntax highlighting and saves the notes to the browser db.
It mentions that the data is processed locally.
I checked the network requests, it does save some data. It included the top channels, num videos watched, and a bit of watching habits.
Would be great to have something like this open-source which is completely browser based.
