therapist

I do exactly this with SSDs outside the array in a BTRFS RAID5 config Very easy to set up https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=462135

unRAID (as when I started with it) helped me get away from the off the shelf NAS products into a much more robust environment. Originally starting with an 8-disk rack server, I quickly added additional DAS devices for more storage...swapped hardware for more VM performance...and now host a media streaming server for 20ish daily users. The server also runs my home LAN dockers, and my daily driver gaming VM....could have done it a million other ways, but unRAID made everything cohesive & simple!

Use the SuperMicro IPMICFG tool to create a new user, then login and change password Tool available here: https://www.supermicro.com/solutions/SMS_IPMI.cfm Copy linux package to accessible dir and use via putty Follow guide here: https://www.servethehome.com/reset-supermicro-ipmi-password-default-lost-login/

of course, new system already has license can data array just be moved to a new system and spun up? will shares auto populate?

My usage with UNRAID has changed over time & I have decided to build a dedicated storage box (low power) & a high power compute box for VMs/PLEX/dockers. I have a single existing system which does everything right now & I'd like to peel out JUST the data array to move to the new storage box -- is it possible to move drives, assign & just recreate parity on a new system? I know I could move the flash drive over (i've upgraded hw over time) but I want to keep my existing dockers/vms on the compute box. Can I copy flash drive contents to new? Any advice?

Version: 6.7.0-rc7 Seeing random segfaults related to musl recently: Apr 8 23:59:32 OCHO kernel: python[34253]: segfault at 6e6f68747988 ip 000014ed29501411 sp 000014ed226c2d38 error 6 in ld-musl-x86_64.so.1[14ed294f4000+45000] Apr 8 23:59:32 OCHO kernel: Code: 48 8b 47 10 48 39 47 18 75 14 89 f1 48 c7 c0 fe ff ff ff 48 d3 c0 f0 48 21 05 1b b6 06 00 48 8b 57 18 48 8b 47 10 48 89 42 10 <48> 89 50 18 48 8b 47 08 48 89 c2 48 83 e0 fe 48 83 ca 01 48 89 57 Apr 9 00:12:33 OCHO kernel: python[2565]: segfault at 561700000090 ip 000014ed2950140d sp 000014ed226c2f08 error 6 in ld-musl-x86_64.so.1[14ed294f4000+45000] Apr 9 00:12:33 OCHO kernel: Code: 83 c0 10 c3 48 8b 47 10 48 39 47 18 75 14 89 f1 48 c7 c0 fe ff ff ff 48 d3 c0 f0 48 21 05 1b b6 06 00 48 8b 57 18 48 8b 47 10 <48> 89 42 10 48 89 50 18 48 8b 47 08 48 89 c2 48 83 e0 fe 48 83 ca have unifi-controller / ombi / nextcloud / resilio-sync / tautulli / duplicati installed from linuxserver repo how do I go about identifying the culprit container? Its not like its happening with any kind of frequency ocho-diagnostics-20190409-1212.zip

Running 6.7.0-rc6 on a supermicro x9dri-ln4f w/ 2x E5-2670v2 & 128gb ECC ram 1x 9211-8i -- 6x drives on array (slot 4) 1x 9207-8i -- 5x non array SSDs + 1x cache SSD (slot 6) 1x 9207-8e -- 4x array drives + 2x non array drives (slot 1) gigabyte gtx 1070 (slot 3) 11 array drives -- 6tb parity Upgraded from x8dti-f w/ 2x l6540 in late January / early February -- had no issues with this system other than lacking a little grunt for PLEX transcoding Ive been having recent issues with call traces which seem to be occurring during parity checks. Noticed them during the previous month's scheduled partiy check (2/28) I had my tunables set to: Tunable (nr_requests): 128 Tunable (md_num_stripes): 4096 Tunable (md_sync_window): 2048 Tunable (md_sync_thresh): 2000 And I've lowered sync_thresh to 192 which alleviated a number of the call traces I was seeing but don't understand why this became an issue after the upgrade when I re-used all hardware other than the mobo/cpu Also, still getting a KVM related call trace at the onset of the parity check -- and NIC dropouts while parity check is running Easy answer is to do parity checks less (I'm on UPS & SONNEN battery) but I'd like to fix the problem... Any advice on where to go? ocho-diagnostics-20190401-1838.zip

there was in fact.... I have: Tunable (nr_requests): 128 default Tunable (md_num_stripes): 4096 user-set Tunable (md_sync_window): 2048 user-set Tunable (md_sync_thresh): 2000 user-set been set this way for quite some time. why would parity check cause KVM lock up?

started getting call traces, which seem to occur when previously functional VMs are running Feb 28 13:58:53 OCHO kernel: CPU: 33 PID: 17724 Comm: unraidd Not tainted 4.18.20-unRAID #1 Feb 28 13:58:53 OCHO kernel: Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 Feb 28 13:58:53 OCHO kernel: Call Trace: Feb 28 13:58:53 OCHO kernel: <IRQ> Feb 28 13:58:53 OCHO kernel: dump_stack+0x5d/0x79 Feb 28 13:58:53 OCHO kernel: nmi_cpu_backtrace+0x71/0x83 Feb 28 13:58:53 OCHO kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Feb 28 13:58:53 OCHO kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Feb 28 13:58:53 OCHO kernel: rcu_dump_cpu_stacks+0x91/0xbb Feb 28 13:58:53 OCHO kernel: rcu_check_callbacks+0x23f/0x5ca Feb 28 13:58:53 OCHO kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Feb 28 13:58:53 OCHO kernel: update_process_times+0x23/0x45 Feb 28 13:58:53 OCHO kernel: tick_sched_timer+0x36/0x64 Feb 28 13:58:53 OCHO kernel: __hrtimer_run_queues+0xb1/0x105 Feb 28 13:58:53 OCHO kernel: hrtimer_interrupt+0xf4/0x20d Feb 28 13:58:53 OCHO kernel: smp_apic_timer_interrupt+0x79/0x91 Feb 28 13:58:53 OCHO kernel: apic_timer_interrupt+0xf/0x20 Feb 28 13:58:53 OCHO kernel: </IRQ> Feb 28 13:58:53 OCHO kernel: RIP: 0010:xor_avx_5+0x1c5/0x352 Feb 28 13:58:53 OCHO kernel: Code: c5 fd 7f 98 e0 00 00 00 c4 c1 7d 6f 82 00 01 00 00 c4 c1 7c 57 83 00 01 00 00 c5 fc 57 83 00 01 00 00 c5 fc 57 85 00 01 00 00 <c5> fc 57 80 00 01 00 00 c5 fd 7f 80 00 01 00 00 c4 c1 7d 6f 8a 20 Feb 28 13:58:53 OCHO kernel: RSP: 0018:ffffc9000b6cfc68 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13 Feb 28 13:58:53 OCHO kernel: RAX: ffff880e118ada00 RBX: ffff880e118a5a00 RCX: ffff880e118a5000 Feb 28 13:58:53 OCHO kernel: RDX: 0000000000000000 RSI: ffff880e118ad000 RDI: 0000000000001000 Feb 28 13:58:53 OCHO kernel: RBP: ffff880e118a4a00 R08: ffff880e118a6000 R09: ffff880e118a7000 Feb 28 13:58:53 OCHO kernel: R10: ffff880e118a7a00 R11: ffff880e118a6a00 R12: 0000000000000a00 Feb 28 13:58:53 OCHO kernel: R13: ffff880e118ad000 R14: ffff880e118a4000 R15: ffff880e118a5000 Feb 28 13:58:53 OCHO kernel: ? xor_avx_5+0x2d/0x352 Feb 28 13:58:53 OCHO kernel: check_parity+0x118/0x349 [md_mod] Feb 28 13:58:53 OCHO kernel: handle_stripe+0xe8a/0x1226 [md_mod] Feb 28 13:58:53 OCHO kernel: unraidd+0xbc/0x123 [md_mod] Feb 28 13:58:53 OCHO kernel: ? md_open+0x2c/0x2c [md_mod] Feb 28 13:58:53 OCHO kernel: md_thread+0xcc/0xf1 [md_mod] Feb 28 13:58:53 OCHO kernel: ? wait_woken+0x68/0x68 Feb 28 13:58:53 OCHO kernel: kthread+0x10b/0x113 Feb 28 13:58:53 OCHO kernel: ? kthread_flush_work_fn+0x9/0x9 Feb 28 13:58:53 OCHO kernel: ret_from_fork+0x35/0x40 Feb 28 14:01:53 OCHO kernel: INFO: rcu_sched self-detected stall on CPU Feb 28 14:01:53 OCHO kernel: 33-....: (1140023 ticks this GP) idle=92a/1/4611686018427387906 softirq=714962/714976 fqs=282448 Feb 28 14:01:53 OCHO kernel: (t=1140024 jiffies g=275169 c=275168 q=9034795) Feb 28 14:01:53 OCHO kernel: NMI backtrace for cpu 33 Feb 28 14:01:53 OCHO kernel: CPU: 33 PID: 17724 Comm: unraidd Not tainted 4.18.20-unRAID #1 Feb 28 14:01:53 OCHO kernel: Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 Feb 28 14:01:53 OCHO kernel: Call Trace: Feb 28 14:01:53 OCHO kernel: <IRQ> Feb 28 14:01:53 OCHO kernel: dump_stack+0x5d/0x79 Feb 28 14:01:53 OCHO kernel: nmi_cpu_backtrace+0x71/0x83 Feb 28 14:01:53 OCHO kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Feb 28 14:01:53 OCHO kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Feb 28 14:01:53 OCHO kernel: rcu_dump_cpu_stacks+0x91/0xbb Feb 28 14:01:53 OCHO kernel: rcu_check_callbacks+0x23f/0x5ca Feb 28 14:01:53 OCHO kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Feb 28 14:01:53 OCHO kernel: update_process_times+0x23/0x45 Feb 28 14:01:53 OCHO kernel: tick_sched_timer+0x36/0x64 Feb 28 14:01:53 OCHO kernel: __hrtimer_run_queues+0xb1/0x105 Feb 28 14:01:53 OCHO kernel: hrtimer_interrupt+0xf4/0x20d Feb 28 14:01:53 OCHO kernel: smp_apic_timer_interrupt+0x79/0x91 Feb 28 14:01:53 OCHO kernel: apic_timer_interrupt+0xf/0x20 Feb 28 14:01:53 OCHO kernel: </IRQ> Feb 28 14:01:53 OCHO kernel: RIP: 0010:unraidd+0xb1/0x123 [md_mod] Feb 28 14:01:53 OCHO kernel: Code: 48 89 12 48 89 52 08 f0 80 62 20 fe f0 ff 42 28 8b 42 28 ff c8 74 02 0f 0b 48 89 df c6 07 00 0f 1f 40 00 fb 66 0f 1f 44 00 00 <4c> 89 ff 41 ff c5 e8 1e ed ff ff 4c 89 ff e8 69 e1 ff ff 48 89 df Feb 28 14:01:53 OCHO kernel: RSP: 0018:ffffc9000b6cfe50 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 Feb 28 14:01:53 OCHO kernel: RAX: 0000000000000000 RBX: ffff880e27bf6268 RCX: ffff880e1643d818 Feb 28 14:01:53 OCHO kernel: RDX: ffff880e129489d8 RSI: 0000000000000046 RDI: ffff880e27bf6268 Feb 28 14:01:53 OCHO kernel: RBP: ffffc9000b6cfeb8 R08: 0000000000000000 R09: ffffc9000b6cfdb8 Feb 28 14:01:53 OCHO kernel: R10: 0000000000000001 R11: ffff880e19d36000 R12: ffff880e27bf6000 Feb 28 14:01:53 OCHO kernel: R13: 0000000001ebd7e8 R14: ffff880e27bf6220 R15: ffff880e129489c8 Feb 28 14:01:53 OCHO kernel: ? md_open+0x2c/0x2c [md_mod] Feb 28 14:01:53 OCHO kernel: md_thread+0xcc/0xf1 [md_mod] Feb 28 14:01:53 OCHO kernel: ? wait_woken+0x68/0x68 Feb 28 14:01:53 OCHO kernel: kthread+0x10b/0x113 Feb 28 14:01:53 OCHO kernel: ? kthread_flush_work_fn+0x9/0x9 Feb 28 14:01:53 OCHO kernel: ret_from_fork+0x35/0x40 can I get some guidance on what I may be looking at here? EDIT: running 6.6.6 diagnostics attached ocho-diagnostics-20190228-1409.zip

@johnnie.black I have a UD RAID0 array currently & have been considering changing to RAID5 Can btrfs balance -dconvert be done on the fly w/ data existing or must the disks be cleared beforehand?

6.6.6 is current stable the releases are Release Candidates which are technically beyond beta but before full release. I'd imagine that since @limetech can only test so many configurations themselves, they rely on the community to see if there are glitches with the thousands of different hardware options people use. Personally, I stick to stable releases...only installing them after they have been in the wild for 2+ weeks Theres nobody twisting arms to run RC software, so no need to be up in arms about the testing process

I have an x9dri-ln4f+ which has a dedicated onboard Intel 602 controller for the "SCU" port which I am trying to pass through to a Win10 VM. I set up a RAID0 array at boot in the controller interface, and after passing through the controller with vfio-id the windows 10 installer doesnt see any drives. I tried using the virtio drivers & even brought in a copy of intel 602 drivers but no love. Any pointers on where to go next? Goal is to pass through a 4 drive RAID0 for a gaming VM.

my apologies, misread that!

I tried again with an Intel PRO 2500 SSD w/ the same results on a 9207-8e w/ expander & a 9211-8i w/ passthrough backplane