Everything posted by ThermalDetonator
-
[Plugin] Spin Down SAS Drives
After successfully using the plugin for months and a problem with the unraid-usb-dongle later, my sas-drive didn´t spin down anymore. Not for one second. I reinstalled the plugin, restarted multiple times but it didn´t help. The problem ist solved by now - it wasn´t the plugin itselve, it wasn´t unraid´s fault.... after i fixed my usb-dongle something went wrong with my appdata-folder. there were processes which continously accessed my sas-hdd, so it never spun down. For all of you who are having problems with the spindown - there could be processes that prevent your hdd from spinning down. Just my 2 cents, maybe it helps one of you guys. i translated via gemini, as i am from germany....... ;) ## Guide to Diagnosing and Troubleshooting Unraid Disk Spindown Issues This guide provides the necessary steps and commands to identify which process is actively keeping your SAS drive (or any disk) from spinning down. ### 1\. Preparation: Identifying the Drive First, you need to find the Mount Point /mnt/diskX) for your SAS drive, as this is the path you will use in all subsequent commands. 1. List Mount Points: df -h *Look for the path you suspect is active (e.g., /mnt/disk4) and note the device name if displayed.* 2. Find the Device Name and Partition UUID (Optional, but helpful): ls -l /dev/disk/by-id *This helps to connect the physical drive to its device name sdX).* ## 2\. Identify Active File Accesses (Fuser) The most effective way to detect a process accessing a directory or file (and thus the disk) is by using the fuser command. Important: Replace /mnt/diskX in the commands below with the actual mount point of your SAS drive (e.g., /mnt/disk4). | Goal | Command | Purpose | | :--- | :--- | :--- | | All Accesses | fuser -m -v /mnt/diskX | Lists all processes that have files open within that directory. | | Detailed Output | lsof /mnt/diskX | (Alternative/Supplementary) Shows a more detailed list of open files and the processes using them. | ### Interpreting the fuser Output: The output will provide one or more PIDs (Process IDs). ``` /mnt/diskX: <user> <PID>c (Example: root 1234c) ``` * PID: The number of the process accessing the disk. * *<user>:** The user running the process. * *c:** Indicates the process has its current working directory in that path. ----- ## 3\. Map PIDs to Containers/Services (PS) Once you have a suspicious PID (e.g., *1234**), use the ps command (Process Status) to find out which container or service that process belongs to. ### A. Mapping by PID Enter the PID to see the full command name: ```bash ps -o pid,user,cmd -p 1234 ``` ### B. Searching Specifically for Docker Processes To display all processes that directly access your SAS drive, which are often part of a Docker container: ```bash ps aux | grep /mnt/diskX ``` *Look in the CMD column for container-related names like /usr/bin/docker-proxy... or the name of an Appdata service.* ----- ## 4\. Common Causes and Final Steps ### A. Check the Volume Configuration The most common cause is a Docker container whose volume settings are configured to write directly to that specific disk: * Ensure that the Appdata directory for active containers is not located on this specific SAS disk, especially if you have duplicated Appdata folders. * Verify that your Docker Image and Libvirt Image (VM storage) are not stored on this SAS disk. If they are, the disk will remain active as long as containers or VMs are running. ### B. Final Troubleshooting Steps 1. Stop the identified service/container based on the PID you found. 2. Attempt a spin down manually through the Unraid GUI. 3. If the spin down is successful, the identified service was the culprit. Adjust the container's volume mapping in Unraid to point to your main Appdata share /mnt/user/appdata/) instead of the specific disk /mnt/diskX).
-
Unterstützung bei Änderung an den Cache-Laufwerken
Danke, ich gehe gerade so vor, wie Du angeraten hast und es scheint funktioniert zu haben. Ich musste die NVME wieder rausnehmen, die einzige Möglichkeit im Cachepool scheint Raid1 zu sein, wenigstens mal habe ich mich totgeklickt und keine Möglichkeit gefunden, die NVME in den Pool zu nehmen und den Raid-Level vorher auszuwählen. Einen zweiten Cachepool halte ich auch für wenig sinnvoll. Ich müsste einem oder mehreren Dockern explizit dieses Cache-Laufwerk zuweisen, das dann aber relativ schnell voll wäre. Macht keinen Sinn....
-
Unterstützung bei Änderung an den Cache-Laufwerken
Hallo Zusammen, ich bräuchte etwas Hilfe zu meinem Cache-"Pool". Ich bin in Sachen Linux eher schlecht bewandert und habe es dennoch gepackt, mir ein zufriedenstellend laufendes Unraid-System mit Immich-, Jellyfin-, SABNZBD-, Netxtcloud- und PiHole-Docker aufzusetzen. Ich nutzte dazu HW, die ich noch hier hatte und ersetze Schritt für Schritt gegen neue Komponenten. Allerdings hab ich jetzt doch einen Fehler gemacht, obwohl ich eher vorsichtig bin, wenn es an die Änderung des laufenden Systems geht. Ich hab soviel Zeit investiert, dass ich mir meine Config nicht zerschiessen will. Aber ich hab jetzt doch einen Schnellschuss gemacht, der evtl. schwer wieder rückgängig gemacht werden kann, bzw. wie mache ich das am Sichersten? Aktuelle Config: 2 TB SATA-Platte 6 TB SAS-Platte (war schonmal in Bezug auf Stromverbrauch der grösste Fehler, da ich einen LSI HBA einsetzen muss) 6 TB Parity-HDD 256GB SSD, die noch rumlag, als Cache. Ich weiss, das ist alles erstmal kein Hammer-System, aber bislang reicht mir die Power. Läuft alles sauber, im idle habe ich aktuell 23W Stromverbrauch bei einem i3 9100 und einem Asus Prime H310-a Rev. 2.0. Es lag noch eine 128GB-NVME rum. Da dachte ich mir - hey, warum den nicht eh knapp bemessenen Cache wenigstens zeitweise mit dem Ding auf 384GB erhöhen? Also rein mit der NVME. Was ich nicht bedacht habe war, dass Unraid diese nun - als Cache konfiguriert - mit der 256GB SSD im Raid1 einsetzt und damit mein Cache geschrumpft ist. Toll für die Redundanz, schlecht für die Speichergröße :) So sieht meine Config aus bzgl. Docker und Co. - VMs habe ich keine: Appdata --> Cache (bleibt dort) System --> Cache (bleibt dort) Rest: Cache --> Array Der Mover verschiebt jede Nacht von Cache auf Array. Meine Frage: Wie kriege ich das ganze nun von Raid1 auf Raid0 geändert, ohne dass ich Docker etc. verliere? Müsste ich Appdata und System umstellen auf "Cache --> Array" bzw. "Array"?