Arno500

Yeah, I think this is what I will do. I'll just change my config. And switch to BTRFS own's implementation.
This will be the simpler and less-dirty implementation.

Then why you started with this RAID BS anyway? I would suspect this USB RAID enclosure is somewhat expensive, isn't it? In my personal opinion RAID with this type of devices is fooling yourself (saying that looking back at experiences with RAID in professional environments for over 20 years), everything already said in this thread here: http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=11857&pid=71617
 
If you're low in money compensate with time and learn why those RAID attemps are crap and why 'business continuity' can't matter that much. Better replace crappy hardware with a good concept (relying on btrfs or ZFS). If the data on the disks has any real value better drop any host implementation that lacks ECC DRAM since without you can forget about data integrity.
 
AFAIK the least expensive RAID implementation that does not suck is still a HP Microserver (with ECC DRAM!)

If a disk starts to throw errors it's time to throw the disk away. Only reasonable solution to deal with this problem
 
Your USB RAID enclosure is the worst you could do in such a situation since it will prevent you from getting further errors reported (I don't know of a single cheap/crap RAID implementation that supports SMART reporting and self-tests) and UNCORRECTABLE data corruption might occur since most if not all of the cheap/crap RAID-1 implementations simply write data to two disks but read only from one later (if this is the disk that already throws errors then you're lost at this point, at least btrfs will tell you that your data is corrupt unlike most other filesystems that do not even realize that data is corrupt).
 
When you're dealing with a failing disk (which is simply insane, analyse the problem or throw it away!) then by refraining from using a cheap/crap USB-RAID implementation btrfs (or ZFS) could help: simply connect both disks directly to the host and use btrfs' own raid-1 implementation. In this case btrfs will write to both disks (data and checksums), then later read data and checksum, thereby detecting corruption, then reading from the 2nd disk, returning the corrected data to the OS and immediately repairing the data on disk (by remapping the failed blocks and storing the data again in redundant form somewhere else on disk). In this mode you can also run SMART selftests and a periodical scrub too.
 
And this RAID-1 implementation is still moronic since RAID is useless crap when you're not running a business and need availability. Instead of wasting one disk for (pseudo-)redundancy use one disk for data and the 2nd for backups (preferrable at another location). Since you already use btrfs it's soooooo easy by doing snapshopts and transferring them to another disk or location (btrfs send/receive feature). But again: Relying in your situation on a crappy USB-RAID box is the worst decision anyway.
 
For all these cheap/crap USB-RAID enclosures there exists only two use cases:
throw them away as fast as possible do some DIY enhancement (most importantly by throwing away the crappy RAID controller inside and then re-using the enclosure for direct connections to the host)

Little bump, and also tried dev kernel, but didn't boot (did it was installed fine ???).

Hmmm,
It may be possible to backport BTRFS functions to the old vanilla kernel...

Hello !
I recently reimaged my BPi M1 with the vanilla headless Debian Jessie from Armbian. But I have two problems:
Main problem (the worst): I have a RAID SATA to USB enclosure (this one: BS-EHD-35/DUALB). After some times and randomly, the drives stops spinning and the enclosure stops itself. I've disabled any power management on hard drive, setup a cron job to write a file every 5 min, disabled autosuspend in usb core...
I didn't have this problem with the legacy kernel. I cannot downgrade to it, because I'm using BTRFS with some non-compatible extensions. Note: this is a server with apache, Deluge, Plex and Sonarr.
Side problems (I can live with if the first is OK): Also, if the drive isn't connected, the BPi won't boot, and after the enclosure stops, the BPi hang and need a force reset to remount the drive and restart services. Tried a udev rule to automate it, but no luck.
 
Don't understand why the enclosure stops itself, it's not really documented, and tried everything I could think.
 
Thank you,
Arno