-
[Plugin] Storage Guard - free-space thresholds so you know if a failed disk still leaves room to move data
This thread is the support topic for Storage Guard.Install the plugin, set your free-space thresholds, and use 'Main' page as usual. For bugs or feedback, post here with Unraid version, a quick note on array/pool layout, and what you expected vs what you saw. Screenshots of Settings and 'Main' help. Drive prices make replacing a failed disk the same day expensive. Storage Guard is a first-glance check on Main: set free-space thresholds for the array and each pool so you can see whether you still have room to move data after a disk fails. When free space falls to or below a threshold, the free space bar on Main is colored yellow (warning) or red (critical). Optional Unraid notifications use the same thresholds. INSTALLATIONPlugins → Install Plugin, paste this URL: https://raw.githubusercontent.com/ibigsnet/StorageGuard/main/storageguard.plg After install: Settings → User Utilities → Storage Guard WHAT IT DOESFree-space Warning and Critical thresholds for the array and each pool Thresholds from real disk sizes, or custom values (1.5T, 500G, 7.5T, etc.) Colors the Main free space bar (solid or outline, per array/pool) Optional Unraid notifications (independent of coloring) COMPATIBILITYTested on Unraid 7.1.3. Plugin allows Unraid 6.12.0+. Main free-bar coloring is built around Unraid 7 layout. Reports from other 7.x builds welcome. LINKSDocs: https://github.com/ibigsnet/StorageGuard/blob/main/DOCS.md GitHub: https://github.com/ibigsnet/StorageGuard Mods: first plugin author — I cannot start a topic in Plugin Support yet. Please move this thread there if appropriate. Thanks.
-
[Mod request] I can't start a topic in Plugin Support yet (first plugin author). Long time supporter.
Hi mods / everyone, I can’t start a topic in Plugin Support yet. This is my first Unraid plugin. I’m a long-time Unraid user/supporter and would like this thread moved to Plugin Support if that’s the right place. Thank you! --- [Plugin] Storage Guard I’m a bit nervous and excited to share this—it’s my first plugin, and I really hope others find it useful. Testing, bug reports, and honest feedback would mean a lot. ### Why I built it Drive prices have gotten painful. I run large Red drives (26TB class). What used to cost me around ~$380 is now well over $1,100 to replace. When a data disk fails, Unraid can keep the array online with parity emulation—but the usual next step is “buy a replacement now.” What I actually want, at a glance on Main, is simpler: Can I still move data off the failed (emulated) disk onto the rest of the array (or free up space another way) without being forced to buy a new drive the same day? If free space is still high enough to evacuate that disk’s data, I have options. If it isn’t, I need to know early—not after the failure—because replacement cost is no longer casual money. Storage Guard is that first-glance check. You set free-space thresholds for the array and each pool. When remaining free space falls to or below a threshold, the total free space bar on Main is colored yellow (warning) or red (critical). Optional Unraid notifications use the same thresholds. ### What it does - Free-space Warning / Critical thresholds for the array and each pool - Thresholds from real disk sizes, or custom values (e.g. 1.5T, 500G, 7.5T) - Colors the Main free space bar (outline or solid, per array/pool) - Optional Unraid notifications (independent of coloring) - Settings under Settings → User Utilities → Storage Guard Full docs: https://github.com/ibigsnet/StorageGuard/blob/main/DOCS.md ### Install Plugins → Install Plugin, paste: https://raw.githubusercontent.com/ibigsnet/StorageGuard/main/storageguard.plg GitHub: https://github.com/ibigsnet/StorageGuard ### Requirements / testing The plugin file currently allows Unraid 6.12.0+, but I’ve only tested on Unraid 7.1.3. Main free-bar coloring is built around Unraid 7’s layout, so if you’re on something else, please try it and tell me what works (or breaks)—I especially want reports from other 7.x builds, and from 6.12 if anyone tries it. ### Looking for testers / feedback This is an early community release. As a first-time plugin author I’m especially keen on real-world testing. Please try it and report back: - Array-only, pools-only, and mixed layouts - Multiple named pools (any names—not only “cache”) - Main free-bar coloring (outline vs solid) - Alerts firing correctly - Anything that breaks after plugin update / uninstall When reporting a bug, please include Unraid version, brief disk/pool layout, what you expected, and what you saw (screenshots of Settings + Main help a lot). Feature ideas are welcome too—especially around how people think about “enough free space to survive a disk loss.” Thanks for reading, and thank you in advance to anyone who tries it. I hope Storage Guard helps you the same way I hoped it would help me. If we move the post, can we title: [Plugin] Storage Guard - free-space thresholds so you know if a failed disk still leaves room to move data
-
-
RifleJock started following Plugin Support
-
unRAID 6 NerdPack - CLI tools (iftop, iotop, screen, kbd, etc.)
Was CTOP removed?
-
Random Shutdowns on x670e and ryzen 7950x
I can confirm, that I run into a lot of these problems as well. I had originally built the 7950x on Asus X670E Extreme. I ended up doing RMA's and other things that left my build in a messy state. While buying and swapping hardware around, I ultimately ended up building a secondary system. The other system, the 7950x3D and x670e Gene, seems to be a lot more stable. I will say that I went away from unraid due to the instability with it. Now both of those systems are on 7950x3D, and I notice, that there are lots of limitations with unraid and the x3D processors as well, having to send data through a specific core, and crashes after reserving specific cores for vm's. I'll be playing around with all the builds again on unraid soon, I'm sure I'll still run into the same issues, but seing as there as been a lot of BIOS updates and Kernel updates with unraid, perhaps there is some stability now? We will see.
-
[Support] ich777 - Gameserver Dockers
How necessary is this process? (using ich777/minecraftbasicserver) --env 'UID=99' \ --env 'GID=100' \ The issue that I'm facing, is that my Minecraft (MC Eternal) server reboots will take literally forever to reboot due to this process. I've got hundreds of gigs of Dynmap and World data, and everytime the container reboots, this process will struggle to go through each of the directories created, mainly Dynmap and World folders will cause this to take forever as there are millions of folders/subdirectories. Can I set the necessary permissions one time, and disable this process from the bootup process?
-
Corsair RMi, HXi, AXi PSU Statistics - CyanLabs's fork
Same boat here, AX1500i. Unraid 6.10.0-rc3 root@CRYZEN:~# lsusb Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 003: ID 0b05:1984 ASUSTek Computer, Inc. USB Audio Bus 005 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 003: ID 1b1c:1c02 Corsair Corsair Link TM USB Dongle Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 010 Device 002: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub root@CRYZEN:~# root@CRYZEN:/sys/bus/usb/drivers# ls -al total 0 drwxr-xr-x 8 root root 0 Mar 19 04:13 ./ drwxr-xr-x 4 root root 0 Mar 19 04:13 ../ drwxr-xr-x 2 root root 0 Mar 19 04:13 hub/ drwxr-xr-x 2 root root 0 Mar 19 04:13 synaptics_usb/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usb/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usb-storage/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usbfs/ drwxr-xr-x 2 root root 0 Mar 19 04:13 usbhid/ root@CRYZEN:/sys/bus/usb/drivers# cd hub/ root@CRYZEN:/sys/bus/usb/drivers/hub# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:08 1-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb1/1-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 10-0:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 2-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb2/2-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 3-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 3-5:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/3-5:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 4-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb4/4-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 5-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 5-1:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-1/5-1:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 6-0:1.0 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb6/6-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 7-0:1.0 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb7/7-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 8-0:1.0 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb8/8-0:1.0/ lrwxrwxrwx 1 root root 0 Mar 19 09:08 9-0:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb9/9-0:1.0/ --w------- 1 root root 4096 Mar 19 09:08 bind lrwxrwxrwx 1 root root 0 Mar 19 09:08 module -> ../../../../module/usbcore/ -rw-r--r-- 1 root root 4096 Mar 19 09:08 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:08 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:08 unbind root@CRYZEN:/sys/bus/usb/drivers/hub# cd ../synaptics_usb/ root@CRYZEN:/sys/bus/usb/drivers/synaptics_usb# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ --w------- 1 root root 4096 Mar 19 09:11 bind -rw-r--r-- 1 root root 4096 Mar 19 09:11 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:11 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:11 unbind root@CRYZEN:/sys/bus/usb/drivers/synaptics_usb# cd ../usb root@CRYZEN:/sys/bus/usb/drivers/usb# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:11 10-1 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 3-5 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 3-5.1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/3-5/3-5.1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 5-1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 5-6 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-6/ --w------- 1 root root 4096 Mar 19 09:11 bind --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:11 unbind lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb1 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb1/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb10 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb2 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:01.0/0000:23:00.0/usb2/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb3 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb3/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb4 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.1/usb4/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb5 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb6 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb6/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb7 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb7/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb8 -> ../../../../devices/pci0000:20/0000:20:08.1/0000:33:00.3/usb8/ lrwxrwxrwx 1 root root 0 Mar 19 09:11 usb9 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb9/ root@CRYZEN:/sys/bus/usb/drivers/usb# cd ../usb-storage/ root@CRYZEN:/sys/bus/usb/drivers/usb-storage# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:12 10-1:1.0 -> ../../../../devices/pci0000:00/0000:00:08.1/0000:03:00.3/usb10/10-1/10-1:1.0/ --w------- 1 root root 4096 Mar 19 09:12 bind lrwxrwxrwx 1 root root 0 Mar 19 09:12 module -> ../../../../module/usb_storage/ -rw-r--r-- 1 root root 4096 Mar 19 09:12 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:12 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:12 unbind root@CRYZEN:/sys/bus/usb/drivers/usb-storage# cd ../usbfs/ root@CRYZEN:/sys/bus/usb/drivers/usbfs# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ --w------- 1 root root 4096 Mar 19 09:13 bind lrwxrwxrwx 1 root root 0 Mar 19 09:13 module -> ../../../../module/usbcore/ -rw-r--r-- 1 root root 4096 Mar 19 09:13 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:13 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:13 unbind root@CRYZEN:/sys/bus/usb/drivers/usbfs# cd ../usbhid/ root@CRYZEN:/sys/bus/usb/drivers/usbhid# ls -al total 0 drwxr-xr-x 2 root root 0 Mar 19 04:13 ./ drwxr-xr-x 8 root root 0 Mar 19 04:13 ../ lrwxrwxrwx 1 root root 0 Mar 19 09:13 5-6:1.7 -> ../../../../devices/pci0000:20/0000:20:01.1/0000:21:00.0/0000:22:08.0/0000:2a:00.3/usb5/5-6/5-6:1.7/ --w------- 1 root root 4096 Mar 19 09:13 bind lrwxrwxrwx 1 root root 0 Mar 19 09:13 module -> ../../../../module/usbhid/ -rw-r--r-- 1 root root 4096 Mar 19 09:13 new_id -rw-r--r-- 1 root root 4096 Mar 19 09:13 remove_id --w------- 1 root root 4096 Mar 19 04:13 uevent --w------- 1 root root 4096 Mar 19 09:13 unbind root@CRYZEN:/sys/bus/usb/drivers/usbhid# ^C root@CRYZEN:/sys/bus/usb/drivers/usbhid#
-
Unable to boot into GUI Mode
It's doing pretty well, though one major issue, can't run a GPU in PCIE slot one, New bios update came out yesterday, was going to do some testing again on it. Having GPU in slot one, board fails to do resets correct. Luckily, managed to get SLI working still using slot 3 and 7. Find it weird that slot 7 is hardware id 1:00:00. Additionally, raw windows 10 thinks the same, that the bottom gpu ends up being the primary. Doing research on other sites about the slot resets failing, I managed to find that it's apparently due to the chipset drivers, AMD has the version that supposedly fixes it labeled as Beta, so Asus doesn't officially include them in the bios updates. They are still using the lastest full release, which has been known to cause issues on Ryzen Threadrippers on gaming boards (which have the beta drivers as a beta bios) as well as the Threadripper Pros. Recommend using another item in the slot 1 as a work around. Anyways, I had once also though that the microSD card slot on the board would work for passthrough. While it did technically, I ended up confusing the licensing as this slot is IPMI passable. As well as some virtual USB's that you can upload files to using the web-ui for the board management. Was weird, because having the system boot, it would change the GUID of the microSD card slot every boot, and additionally, if I installed my valid USB, the licensing would see it correctly, and think its writing to the usb flash drive, but would actually write to the SD card (which showed up as flash). But os would see the usb's capacity and licensing. Other than that, or and the Kernel not showing a supported CPU on boot, it all has been working okay I suppose. Lots of troubleshooting for sure, and 6.10 rc2 is allowing the gui to work in UEFI boot, and tpm2.0 passthrough works as well. both cpu based and motherboard/hardware based. DM me or something if you have more detail questions or are interested in the board, can do some testing for you.
-
Cant see my share folder after update to 6.10.1 rc1
I've ran into this same problem multiple times as well. Now that I'm on a new system, I'm certain it's not the hardware that's at fault. I think I've narrowed it down, I've wiped and re-installed my flashdrive back to 6.9.3. I've rebuilt all my docker containers (I also use the vm/docker folders plugin) when on 6.9.3. Then, I upgrade (causing shares's settings to disable). I then re-enable the shares. All shares, disks and folders go missing. Trying from a fresh install using the windows flash creation/installation tool, I install 6.10.0-rc1. This time, enabling the shares appears to work. Next, the docker container's show they are errored, and that the images are missing. I delete and re-download them. Once completed, after a short time, my shares appear to go missing... I'm also running parity re-build in the background since it's a new OS, and I happened to add two drives. Once the parity build starts, it doesn't appear to like being paused. Logging also has stopped working through the web-ui since the disappearance of the shares. I can spin disks up, (the 1 and 2TB disks spun down, since party is still going, but not read from them.) But once spun up, they appear to not want to spin down manually again. I have to wait for my disk settings' 45 minute timer to kick off the spin down. On the first few attempts at a fresh install, after editing networking and other settings, I managed to get to a state where the web-ui was completely unresponsive, booting locally to the gui was also not working as I continued to get the plagued blinking cursor. I ran a tcpdump and saw my connections coming into the system, but the system did not respond to the web-ui requests. Also attempted multiple browsers. It appeared as if a core service of the web-browser was failing to start on startup. This last go around, the web-ui is sluggish, but working... The only thing I hadn't changed this last time compared to the first few attempts, was any networking settings (from the initial install to the flashdrive) as well as the identification settings. Same with management access (other than enabling ssh). Changing those before ended up leading to no web-ui. I'm not sure why this version seems to have issues when it comes to the web-ui, but there are too many things "fixed" from the previous versions, that I don't want to go back. For instance, even with "nomodeset", my ASPEED VGA adapter from the BMC's IPMI appears to be working now when booting UEFI (other than when the web-ui becomes completely unresponsive.) PS: Also, I'm only working in UEFI booting mode, as is required on this system to get all NVMe's and Sata drives to show up. Maybe a limitation of the bios, working with Asus to resolve those related issues. Here is the diagnostics. IDK what else I'm missing, not really sure of a lot of things when it comes to the software side of it. If anyone has any suggestions or questions, please let me know. Edit: I just realized my "user" folder has gone missing... what could cause this? cryzen-diagnostics-20211025-1004.zip So, I'm guessing something happened to bzmodules or something? and the user mount is unknown now? IDK, I'm too n00b to figure anything else out, I'll wait for a senior.
-
Unable to boot into GUI Mode
Looks like I still have this problem as well... I had thought it was just my hardware, seen with UEFI and Legacy, I've tried every CSM variation in my bios, even trying older and newer bios's. Asus z10pe-d16 ws. Board ended up dying a while back, and I ended up upgrading to the Asus PRO WS wrx80e SAGE SE WIFI, this uses a similar IPMI and BMC setup as the previous board, both used an ASPEED (VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41)) This one being a newer revision. Not sure what I'm missing. I hadn't tried other modes, but I suspect that CSM usage and legacy boot will allow the gui to work once again. (version 6.9.2) cryzen-diagnostics-20211022-0913.zip cryzen-diagnostics-20211024-1119.zip
-
Corsair RMi, HXi, AXi PSU Statistics - CyanLabs's fork
Hello all, curious the status of this plugin. Noticed my AX1500i isn't being recognized. Anyone else have an AX1500i working?
-
Add qemu ARM support for raspberry pi virtualization
+1
-
[PLUGIN] GPU Statistics
I'm down to be a guinea pig for the multi-gpu tests... I'm sure I have some AMD's laying around somewhere I could slap in there as well to test cross vendor support. Also, I've noticed that they have some vGPU support when it comes to the Intel iGPU's... I'm curious if we can get stats on those as well.
-
Do you use spin up groups?
While that is a valid point and what I currently do with my anime directories (for plex and other media servers). The goal with the GoPro libraries was not for that of economics, but rather, of performance from the array disks. With the anime libraries, it's setup to where a disk is accessed based on the series you are watching. If you decided to binge the series, the disk will stay spun up as the shows usually don't exceed 45 minutes (post full read and cache of the at each start of an episode) of which, is my disk spin down setting time. For instance Plex will read a disk at the start of an episode. Go full ape in transcode based on your transcode settings. Transcoded files then sit on the cache to be read back live during your stream. If the disk spun down, and the user either decided to change their quality settings, skip the episode at some point, or scrub backwards (sometimes, transcodes are discarded and need to be rerecorded (this was back in the day.. transcodes stick around a little longer now.).). Anyways, it just so happens that 45 minutes until spin-down works perfectly in all the scenarios that I could reference in my system. That combined with specific directory splitting, or disk allocation methods, I've not had to use the spin-up groups as of yet.. though I'm starting to see more of a need for them...
-
Do you use spin up groups?
I've never used them. However, was considering it now, but seeing as they might go away, may consider not using them. I had a use case before, when I used 6x 8TB drives. This was on my Media share, where I had used "most-free" and changed the directories split such that each 30 minute GoPro video would be placed among these drives evenly. I would do this so that when reading videos from these drives whilst doing video editing that would reference 4 or 5 videos from the trip of the day, I could get full sequential reads from the Array disks per video. In order to prevent spin-downs, my work around would be to set the disk spin down delay to that of 45 minutes, that way, it was harder for the drive to spin down, while reading from all the drives.
-
Virtual firewall running on unraid
So there is a big difference here... Your physical environment, and your virtual one. All things done within UnRAID are considered your virtual environment, and everything outside of that is considered your physicals. You can either setup UnRAID to have a L2 interface, of which you pass through as a bridge to your virtualized Palo Alto. (There wouldn't be much of a point in running a L2 within Palo if this is the case.) This will allow your Palo to communicate only on that physical L2 interface of UnRAID when trying to communicate with anything else on that same L2 interface in your physical environment. Perhaps a real Palo Alto with the same VLAN tagging for redundancy or whatever. Now lets say you have a virtual Check Point device and a virtual Palo both on your unraid, regardless of what physical interfaces are assigned in UnRAID, whatever bridge you passthrough to the virtual environments, you can create L2 interfaces within your CheckPoint and Palo Devices, and only devices on that same bridge (on UnRAID) in the same virtual L2 LAN will communicate. However, I believe any traffic destined to a network outside of UnRAID will get put onto UnRAID's physical configuration's interface when it is attempting to leave the UnRAID box itself. If your UnRAID is configured as a physical L3 with default tagging, then traffic will leave tagged as such. This type of configuration only separates the virtual traffic within the UnRAID box. Depending on what your scenario is, you could do either or both. It all comes down to your physical and virtual topology. LMK if you have any further questions, I can break this down further if needed. -Jockie.