josetann

I've read about issues with btrfs, but haven't seen anything saying WHY. I've only used btrfs in a proxmox setup with two 1TB NVME drives in a mirror, with unRAID I've only used xfs (except when unRAID was ReiserFS only, but we don't talk about that). So you're saying that if I use at least somewhat quality hardware (currently using enterprise drives, I have used SMR consumer drives in the past though) and have ECC RAM (so shouldn't have ram issues), I shouldn't have the issues others are reporting with btrfs? Do you think it's more reliable than zfs with semi-quality hardware?

It may still be the recommendation. I've had literally zero problems using xfs, I have no problem recommending it. I just really like the idea of being able to take snapshots (I had a nightmare where one of my family members who knew better, clicked something they shouldn't and now everyone's mad at me because I should have known about ransomware). I've been a bit lazy when it comes to proper backups, snapshots would help mitigate some of the risk that's a result of said laziness. Plus it's cool, I like cool.

Currently have two mechanical 14TB drives (neither SMR) with one data and one parity. Doing a new build, something a tiny bit more power efficient than my Z420. Going to replace one of the 14TB drives with a 15.36TB U.2 SSD. Don't worry, I've already been told that I should under no circumstances use an SSD as a drive in an unRAID array, but I'm going to anyway 😀 Currently using xfs, but I'd really, REALLY like to have native snapshot support. I figure now is as good a time as any to change filesystems, so, what would you do? Switch to the new hotness ZFS, because it's new and awesome and features!!!! Switch to BTRFS. It's not as flashy, but it is a bit more mature...at least when it comes to unRAID support. Stay with XFS, snapshots are for wimps! I wouldn't be looking to setup a ZFS pool as cache, so I know that a lot of ZFS's awesomeness would be lost on my setup (just a single drive/vdev in an array, plus a mechanical drive for parity). I also don't need ZFS's ability to eat RAM to speed up access, since the data drive would be an enterprise ssd. Yes, writes would be abysmally slow, but that hasn't been a concern yet (read speeds are another issue, I'm having the infamous MacOS smb issues, but I've stopped messing with that until the new system is up and running). One minute I'm leaning ZFS because it really was made for this, even if I'm severely limiting its potential; the next minute I'm leaning toward BTRFS because I envision much lower system resource usage and better overall stability (not because BTRFS is better than ZFS, but because there's been more time to work out the kinks between unRAID and BTRFS). Or perhaps I should just rip out the old data drive, throw in the new U.2 drive, do a rebuild, and ask again next decade.

I have a Windows 10 VM that's working decently after some troubleshooting (needed to enable MSI mode on nvidia graphics/sound, else it could bring entire unraid server down when the VM was powered off/rebooted). I have an issue that I've worked around, but it still bugs me (you know how it is). I bought a Sonnet Allegro Pro USB 3.0 PCIe card with four dedicated controllers (one controller per usb port). One is passed through to the Windows 10 VM. I have a cheap four port hub plugged in so anything I plug into the hub is connected directly to the VM. Needed it this way so I could use a usb amp (when it's turned off it's not visible to the OS, i.e. unplugged). Anyway.... The Windows 10 VM hangs at the bios screen (where it shows it passed the memory check) if the IR receiver is plugged in. Doesn't matter if the IR receiver is plugged into the usb hub, or plugged directly into the dedicated usb port. Just hangs there. I can unplug, boot, then plug the receiver in, works fine until I reboot. It doesn't have an issue with the other usb devices (currently a Logitech unifying usb adapter and an SMSL amp). Simple workaround, I have the IR receiver plugged into one of the shared usb ports and assigned it to the Windows 10 VM. Works fine, but it still bugs me, you know? IR receiver info: TopSeed Technology Corp. eHome Infrared Transceiver (1784:0006) Dedicated usb controller info: Fresco Logic FL1100 USB 3.0 Host Controller | USB controller (09:00.0) Syslog when booting with the IR receiver plugged into the hub (VM hangs): Oct 11 19:12:36 Tower kernel: vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Oct 11 19:12:36 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:12:36 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 11 19:12:36 Tower kernel: device vnet1 entered promiscuous mode Oct 11 19:12:36 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:12:36 Tower kernel: br0: port 3(vnet1) entered forwarding state Oct 11 19:12:38 Tower kernel: vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19@0x900 Oct 11 19:12:38 Tower kernel: vfio-pci 0000:09:00.0: enabling device (0400 -> 0402) Syslog when booting without the IR receiver plugged in (VM boots, can plug in once Windows boot screen displays): Oct 11 19:13:34 Tower kernel: vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Oct 11 19:13:34 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:13:34 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 11 19:13:34 Tower kernel: device vnet1 entered promiscuous mode Oct 11 19:13:34 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:13:34 Tower kernel: br0: port 3(vnet1) entered forwarding state Oct 11 19:13:36 Tower kernel: vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19@0x900 Oct 11 19:13:36 Tower kernel: vfio-pci 0000:09:00.0: enabling device (0400 -> 0402) Oct 11 19:13:47 Tower kernel: kvm: zapping shadow pages for mmio generation wraparound Oct 11 19:13:47 Tower kernel: kvm: zapping shadow pages for mmio generation wraparound I don't see anything useful. If there's any additional information you'd like, just let me know. Edit: In case it helps, here's a syslog of the Windows 10 VM successfully booting with the current setup (dedicated usb port passed through, plus the IR receiver passed through separately): Oct 11 19:38:16 Tower kernel: vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=io+mem:owns=none Oct 11 19:38:16 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:38:16 Tower kernel: br0: port 3(vnet1) entered disabled state Oct 11 19:38:16 Tower kernel: device vnet1 entered promiscuous mode Oct 11 19:38:16 Tower kernel: br0: port 3(vnet1) entered blocking state Oct 11 19:38:16 Tower kernel: br0: port 3(vnet1) entered forwarding state Oct 11 19:38:18 Tower kernel: vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19@0x900 Oct 11 19:38:18 Tower kernel: vfio-pci 0000:09:00.0: enabling device (0400 -> 0402) Oct 11 19:38:20 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:20 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:26 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:27 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:27 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:30 Tower kernel: kvm: zapping shadow pages for mmio generation wraparound Oct 11 19:38:30 Tower kernel: kvm: zapping shadow pages for mmio generation wraparound Oct 11 19:38:31 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:31 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:32 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:32 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:35 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:36 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:36 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:37 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:37 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci Oct 11 19:38:37 Tower kernel: usb 1-1.6: reset full-speed USB device number 4 using ehci-pci