Dustiebin Posted July 10, 2023 Share Posted July 10, 2023 On 5/13/2023 at 8:35 PM, suppa-men said: Hi all i encountered the same issue on my Dell T340 with a Dell HBA330 connected to a backplane which supports SAS and SATA. My 4x SAS drives spun down while my 4x Sata disks remain up. I was able to spin down a SATA disk manually by executing sg_start -rp3 /dev/sdi . So i modified the drive_types file and tagged a SATA disks as SAS. After that i was also able to spin down the SATA disks over the UI. Is there an easy way to tag all devices, which are connected to that backplane as SAS? @suppa-men Sorry for the late response. Did not see a notification for the message. anyway, I fixed my issue by getting a different HBA card. My original card failed so had to get a new one. The new one does not have the issue of the old where a drive would spin down only to spin up minutes later. My only guess is that the old card has a bug in it...... but that is a guess. Model I got of ebay: Dell PERC H310 SAS Card PCIe LSI 9211-8i 2x Internal Ports Quote Link to comment
Jetracer Posted August 2, 2023 Share Posted August 2, 2023 I recently bought a new sas drive, a Seagate ST8000NM0065. It is plugged into an Adaptec 7805 in hba mode. The drive formatted fine and it spun down fine. However it would not spin back up and Unraid disabled the drive. I'm not sure if this is possibly a drive/hba mismatch, I did order another hba to test with. Any help or insight is appreciated. tower-diagnostics-20230730-1935.zip Quote Link to comment
doron Posted August 2, 2023 Author Share Posted August 2, 2023 @Jetracer , this is unfortunately a commonly reported phenomenon with Seagate SAS drives. The drive/hba combo interprets the spin down instruction somewhat differently than other drives. I don't have a good solution to offer.Sent from my tracking device using Tapatalk Quote Link to comment
stottle Posted August 13, 2023 Share Posted August 13, 2023 I've got Seagate SAS drives and an LSI HBA. Sounds like there are variations of Seagate + controllers that don't work, but the UI/log seems to show my drives spinning down. But they almost immediately spin back up. Before I installed this plugin, requesting a spin down of one of the SAS drives appeared to be a no-op (the green circle would not change). After installation (actually setting the spin down to never, rebooting, setting to 1 hr, rebooting, and then installing the plugin) now shows a spinner, then gray for the a drive, but quickly spins back up. The log simply says Aug 13 12:17:40 SuperTower emhttpd: spinning down /dev/sdd Aug 13 12:17:40 SuperTower SAS Assist v2022.08.02: Spinning down device /dev/sdd Aug 13 12:17:57 SuperTower emhttpd: read SMART /dev/sdd I have turned off docker and VMs, and have basically no data on these drives yet so nothing should be trying to access the drive other than Unraid itself. I'm on 6.12.3 if that matters. Any suggestions for fixing this or troubleshooting? Quote Link to comment
Bcy Posted September 10, 2023 Share Posted September 10, 2023 On 11/28/2022 at 3:30 AM, DiRiN said: I looked into the File Activity plugin as suggested. I was having issues with it, and with investigating how to get it to work I had installed the Fix Common Problems / Tips and Tweaks Plugin. I then adjusted the Tips and Tweaks plugin setting for Max Watches 'fs.inotify.max_user_watches': to 6524288 and changed the settings of the File Activity Plugin to the following: After making all the above changes to get the Plugin for FIle Activity to work correctly, then my SAS Spindown started working correctly. lol. So now I have no idea what was causing it. But if I had to make a guess it's the inotify changes I made in Tips and Tweaks. I'll leave it as it is now that it's working. Odd little workaround, that the changes required for one to work properly causes this plugin to work properly. System Logs as of now: ----------------------------------------- Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdm Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdj Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdk Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdh Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdg Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdd Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sde Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdb Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdr Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdf Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdc Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sds Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdq Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdl Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdi Nov 27 20:04:09 Tower emhttpd: spinning down /dev/sdp Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdm Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdk Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdj Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdg Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdh Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sde Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdc Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdd Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdb Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdf Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdi Nov 27 20:04:09 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdl I have to thank you . really helpful . Quote Link to comment
lazant Posted September 11, 2023 Share Posted September 11, 2023 On 4/24/2023 at 4:26 PM, doron said: Oddly, I have never compiled a list of drives that do perform nicely with the spin down/up SCSI/SAS commands. I have collected a list of exclusions - i.e. drives (or drive/controller combos) that misbehave, or otherwise known to either ignore the spin down command or create some sort of breakage upon receiving them. It might be a good idea to compile success stories into such a list. I'll kick it off: I have a few HUH721212AL4200 (12TB HGST) on an on-board supermicro SAS controller (LSI 2308). They spin down and up rather perfectly. I have 7x WUH721818AL5204 18TB SAS Drives on an LSI-3008 that also spin down fine. The activity light on the front of the trays do flash every second but the drives stay spun down. Anyone else experience this flashing every second? Mine are in a supermicro 826 chassis with the EL1 backplane. 1 Quote Link to comment
DeanMarkTaylor Posted October 1, 2023 Share Posted October 1, 2023 Thank you @doron for this "Spin Down SAS Drives" plugin... ... just wanted to report that "it works"! I was initially disappointed as I did see clicking the green dot next to the drive to "spin down" the drive would show spinning arrows and then NOT turn grey, the drive did not spin down. To fix this I simply needed to restart the computer after installing the plugin. For reference SAS drives are TOSHIBA MG08SCA16TE 16TB connected to a LSI SAS2308. 1 Quote Link to comment
dunee Posted December 14, 2023 Share Posted December 14, 2023 I can't figure this out on my own. Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdm Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdj Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdk Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdh Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdg Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sde Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdc Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdl Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdi Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdj Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdh Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdg Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdk Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdi Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdl Dec 14 11:44:35 Tower emhttpd: read SMART /dev/sdm Dec 14 11:47:54 Tower emhttpd: read SMART /dev/sdg Dec 14 11:48:12 Tower emhttpd: read SMART /dev/sdh Dec 14 11:48:23 Tower emhttpd: read SMART /dev/sdi Dec 14 11:48:36 Tower emhttpd: read SMART /dev/sdj Dec 14 11:48:48 Tower emhttpd: read SMART /dev/sdk Dec 14 11:49:00 Tower emhttpd: read SMART /dev/sdl I have a mixture of SATA and SAS drives. The SATA drives stay spun down, the SAS drives spin up, one after the other, within a few minutes. I've shut down my dockers, this still happens. The open files plugin does not show any files being touched when the drives spin up - especially since the SAS drives have no files on them. root@Tower:~# /usr/local/emhttp/plugins/sas-spindown/sas-util SAS Spindown Utility (v20210201.01) ls: cannot access '/dev/disk/by-path/*-sas-*': No such file or directory Error: No SAS drives detected. Now exiting. root@Tower:~# ls /dev/disk/by-path/ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0@ pci-0000:02:00.0-scsi-0:0:12:0-part1@ pci-0000:02:00.0-scsi-0:0:6:0@ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:1:0@ pci-0000:02:00.0-scsi-0:0:6:0-part1@ pci-0000:02:00.0-scsi-0:0:0:0@ pci-0000:02:00.0-scsi-0:0:1:0-part1@ pci-0000:02:00.0-scsi-0:0:7:0@ pci-0000:02:00.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:2:0@ pci-0000:02:00.0-scsi-0:0:7:0-part1@ pci-0000:02:00.0-scsi-0:0:10:0@ pci-0000:02:00.0-scsi-0:0:2:0-part1@ pci-0000:02:00.0-scsi-0:0:8:0@ pci-0000:02:00.0-scsi-0:0:10:0-part1@ pci-0000:02:00.0-scsi-0:0:4:0@ pci-0000:02:00.0-scsi-0:0:8:0-part1@ pci-0000:02:00.0-scsi-0:0:11:0@ pci-0000:02:00.0-scsi-0:0:4:0-part1@ pci-0000:02:00.0-scsi-0:0:9:0@ pci-0000:02:00.0-scsi-0:0:11:0-part1@ pci-0000:02:00.0-scsi-0:0:5:0@ pci-0000:02:00.0-scsi-0:0:9:0-part1@ pci-0000:02:00.0-scsi-0:0:12:0@ pci-0000:02:00.0-scsi-0:0:5:0-part1@ I have an Dell R730xd with an H330 controller in HBA mode (so not flashed to IT mode). Looks like it is presenting all drives as SCSI drives. The recalcitrant SAS drives all appear to be Seagates. Anyone has any ideas on how to fix this? I got an H330 controller so I wouldn't need to flash to IT mode, but at this point I'm seriously considering it. Just worried I'll mess up. Thanks! Quote Link to comment
doron Posted December 14, 2023 Author Share Posted December 14, 2023 4 hours ago, dunee said: I can't figure this out on my own. Let's break this into parts: 4 hours ago, dunee said: Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdm Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdj Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdk Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdh Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdg Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sde Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdc Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdl Dec 14 11:44:17 Tower emhttpd: spinning down /dev/sdi Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdj Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdh Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdg Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdk Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdi Dec 14 11:44:17 Tower SAS Assist v2022.08.02: Spinning down device /dev/sdl Dec 14 11:44:35 Tower emhttpd: read SMART /dev/sdm Dec 14 11:47:54 Tower emhttpd: read SMART /dev/sdg Dec 14 11:48:12 Tower emhttpd: read SMART /dev/sdh Dec 14 11:48:23 Tower emhttpd: read SMART /dev/sdi Dec 14 11:48:36 Tower emhttpd: read SMART /dev/sdj Dec 14 11:48:48 Tower emhttpd: read SMART /dev/sdk Dec 14 11:49:00 Tower emhttpd: read SMART /dev/sdl I have a mixture of SATA and SAS drives. The SATA drives stay spun down, the SAS drives spin up, one after the other, within a few minutes. If the re-spin happens within a few minutes (rather than a couple of seconds), then it's almost certain that either (a) someone is issuing i/o against the drive or (b) some plug-in has waken up and is spinning the drive up, either rightly or erroneously (we've seen both - e.g. an old version of the autofan plugin used to do the wrong thing when inquiring about the drives, which would wake up all SAS drives). Have you looked at your plugins? Can you disable them all and try? Then, if the issue goes away, you can add them back one by one. 4 hours ago, dunee said: I've shut down my dockers, this still happens. The open files plugin does not show any files being touched when the drives spin up - especially since the SAS drives have no files on them. root@Tower:~# /usr/local/emhttp/plugins/sas-spindown/sas-util SAS Spindown Utility (v20210201.01) ls: cannot access '/dev/disk/by-path/*-sas-*': No such file or directory Error: No SAS drives detected. Now exiting. root@Tower:~# ls /dev/disk/by-path/ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0@ pci-0000:02:00.0-scsi-0:0:12:0-part1@ pci-0000:02:00.0-scsi-0:0:6:0@ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:1:0@ pci-0000:02:00.0-scsi-0:0:6:0-part1@ pci-0000:02:00.0-scsi-0:0:0:0@ pci-0000:02:00.0-scsi-0:0:1:0-part1@ pci-0000:02:00.0-scsi-0:0:7:0@ pci-0000:02:00.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:2:0@ pci-0000:02:00.0-scsi-0:0:7:0-part1@ pci-0000:02:00.0-scsi-0:0:10:0@ pci-0000:02:00.0-scsi-0:0:2:0-part1@ pci-0000:02:00.0-scsi-0:0:8:0@ pci-0000:02:00.0-scsi-0:0:10:0-part1@ pci-0000:02:00.0-scsi-0:0:4:0@ pci-0000:02:00.0-scsi-0:0:8:0-part1@ pci-0000:02:00.0-scsi-0:0:11:0@ pci-0000:02:00.0-scsi-0:0:4:0-part1@ pci-0000:02:00.0-scsi-0:0:9:0@ pci-0000:02:00.0-scsi-0:0:11:0-part1@ pci-0000:02:00.0-scsi-0:0:5:0@ pci-0000:02:00.0-scsi-0:0:9:0-part1@ pci-0000:02:00.0-scsi-0:0:12:0@ pci-0000:02:00.0-scsi-0:0:5:0-part1@ Ah. That is unrelated to the above and seems to indicate an issue with that script. It may be incompatible with your controller, other firmware or kernel version. I'll look into that later but the actual plugin code is unrelated (and does not use this method to detect SAS drives - proof is: You do get the "SAS Assist" messages, meaning that the plugin has indeed acted on your SAS drives). 4 hours ago, dunee said: I have an Dell R730xd with an H330 controller in HBA mode (so not flashed to IT mode). Ah, Dell servers. Gotta love them (I do, actually), but they have so many firmware layers that you can sometimes lose track of who did what... I do hope it is not some firmware code that causes the drives to spin up. I wouldn't bother with the IT mode thing; you do have it in HBA mode which is what we need. 4 hours ago, dunee said: The recalcitrant SAS drives all appear to be Seagates. We've seen issues with Seagate drives not spinning down. However, having them spin up after a few minutes is not one of them. Quote Link to comment
dunee Posted December 18, 2023 Share Posted December 18, 2023 Thanks Doron for such a quick reply! I'm disabling my plugins one by one, hope to catch the causing this. Also appreciate the additional details on the controller not having to be reflashed and the Seagate drives not spinning down. I'll keep digging. Quote Link to comment
Toibs Posted January 24 Share Posted January 24 (edited) Just to say - I have exactly the same base hardware (other than the controller) and issues as you @dunee and see the same results. SAS Spindown Utility (v20210201.01) ls: cannot access '/dev/disk/by-path/*-sas-*': No such file or directory Error: No SAS drives detected. ls /dev/disk/by-path/ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0@ pci-0000:00:1a.0-usb-0:1.2:1.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:0:0@ pci-0000:02:00.0-scsi-0:0:0:0-part1@ pci-0000:02:00.0-scsi-0:0:12:0@ pci-0000:02:00.0-scsi-0:0:13:0@ pci-0000:02:00.0-scsi-0:0:13:0-part1@ pci-0000:02:00.0-scsi-0:0:1:0@ pci-0000:02:00.0-scsi-0:0:1:0-part1@ pci-0000:02:00.0-scsi-0:0:2:0@ pci-0000:02:00.0-scsi-0:0:2:0-part1@ pci-0000:02:00.0-scsi-0:0:3:0@ pci-0000:02:00.0-scsi-0:0:3:0-part1@ pci-0000:02:00.0-scsi-0:0:4:0@ pci-0000:02:00.0-scsi-0:0:4:0-part1@ I'll do similar and see if i have any luck my end, and report back! All my drives are ST6000NM0034 drives... running on a Perc H730 Mini Raid controller (different controller). I didnt re-flash it purely because it worked as-was out of the box (rightly or wrongly!). I did go into the H730 config and mark each drive as non-raid though, so didnt do everything wrong. For info, see here : https://www.dell.com/community/en/conversations/poweredge-hddscsiraid/dell-r730xd-with-perc-h730-and-non-raidhba-mode/647f4c61f4ccf8a8de5076c2 Edited January 24 by Toibs Quote Link to comment
xyzeratul Posted February 2 Share Posted February 2 This plugin shows up in my recommendation, I was wonder if I need this, running 2 SAS drive in my array with 4 other SATA drives, unraid 6.12.6. Quote Link to comment
SimonF Posted February 2 Share Posted February 2 5 hours ago, xyzeratul said: This plugin shows up in my recommendation, I was wonder if I need this, running 2 SAS drive in my array with 4 other SATA drives, unraid 6.12.6. SAS drives will not spin down with stock Unraid. Quote Link to comment
xyzeratul Posted February 18 Share Posted February 18 On 2/2/2024 at 3:28 PM, SimonF said: SAS drives will not spin down with stock Unraid. Thanks, I install this one and now all my sas drive can spin down, I never noticed before cuz my sas drives usually had something running. Quote Link to comment
Elmojo Posted February 24 Share Posted February 24 So I have a bunch of drives, all SAS. My array spins down fine (using this plugin), as do the drives in my external MD1200 disk shelf. However, my internal ZFS pool, which are Seagate drives (I see issues noted above), are not spinning down at all. I've scanned the last page or so, and didn't see a solution. Is there any way to get them to calm down, or am I stuck with 5x drives running forever? I did discover that I can manually spin down that pool from the Main tab. I never saw that option before. When I do that, the drives show the little green "working" symbol, but they never go gray until I leave the page and come back. That does seem to work, though. Any thoughts? 1 Quote Link to comment
doron Posted February 24 Author Share Posted February 24 Any thoughts?Some quick questions:1. Under normal operation, are you seeing log messages with "SAS Assist" prefix?2. When you manually spin down your zfs pool, are you seeing any? Can you post them?3. Can you post the output ofls -la /dev/disk/by-path(Or, you can just post diagnostics)Sent from my tracking device using Tapatalk Quote Link to comment
Elmojo Posted February 24 Share Posted February 24 8 hours ago, doron said: Some quick questions: 1. Under normal operation, are you seeing log messages with "SAS Assist" prefix? 2. When you manually spin down your zfs pool, are you seeing any? Can you post them? 3. Can you post the output of ls -la /dev/disk/by-path (Or, you can just post diagnostics) 1. Yes, I do appear to be seeing some of those. Not sure which drives those msgs apply to, though. I can track them down by dev code if you want. Feb 24 08:41:52 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdk Feb 24 08:42:11 Tower emhttpd: spinning down /dev/sdl Feb 24 08:42:11 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdl Feb 24 08:42:30 Tower emhttpd: spinning down /dev/sdm Feb 24 08:42:30 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdm Feb 24 08:43:33 Tower emhttpd: read SMART /dev/sdj Feb 24 08:43:46 Tower emhttpd: read SMART /dev/sdk Feb 24 08:43:58 Tower emhttpd: read SMART /dev/sdl Feb 24 08:44:10 Tower emhttpd: read SMART /dev/sdm Feb 24 08:48:21 Tower emhttpd: spinning down /dev/sdn Feb 24 08:48:22 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 08:49:20 Tower emhttpd: read SMART /dev/sdn Feb 24 09:19:22 Tower emhttpd: spinning down /dev/sdn Feb 24 09:19:22 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 09:19:40 Tower emhttpd: read SMART /dev/sdn 2. Yes, I see the SAS assist line there as well. And I see that it's the same devices as above. I guess that means it's working, but something is waking up the pool? There's absolutely nothing on those drives yet, I wonder what could be waking it...? Feb 24 09:43:06 Tower emhttpd: spinning down /dev/sdn Feb 24 09:43:06 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdn Feb 24 09:43:24 Tower emhttpd: spinning down /dev/sdj Feb 24 09:43:24 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdj Feb 24 09:43:43 Tower emhttpd: spinning down /dev/sdk Feb 24 09:43:43 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdk Feb 24 09:44:01 Tower emhttpd: spinning down /dev/sdl Feb 24 09:44:01 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdl Feb 24 09:44:20 Tower emhttpd: spinning down /dev/sdm Feb 24 09:44:20 Tower SAS Assist v2024.02.18: Spinning down device /dev/sdm AHA!! I just watched the log, and when it read the SMART codes for those drives, they woke up. That appears to be the culprit...maybe? Feb 24 09:44:57 Tower emhttpd: read SMART /dev/sdj Feb 24 09:45:10 Tower emhttpd: read SMART /dev/sdk Feb 24 09:45:22 Tower emhttpd: read SMART /dev/sdl Feb 24 09:45:34 Tower emhttpd: read SMART /dev/sdm Feb 24 09:45:46 Tower emhttpd: read SMART /dev/sdn 3. Sure... root@Tower:~# ls -la /dev/disk/by-path total 0 drwxr-xr-x 2 root root 1080 Feb 18 17:10 ./ drwxr-xr-x 7 root root 140 Feb 18 17:09 ../ lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:00:1d.0-usb-0:1.4:1.0-scsi-0:0:0:0 -> ../../sda lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:00:1d.0-usb-0:1.4:1.0-scsi-0:0:0:0-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:0:0-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:10:0 -> ../../sdl lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:10:0-part1 -> ../../sdl1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:11:0 -> ../../sdm lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:11:0-part1 -> ../../sdm1 lrwxrwxrwx 1 root root 9 Feb 24 04:40 pci-0000:03:00.0-scsi-0:0:12:0 -> ../../sdn lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:12:0-part1 -> ../../sdn1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:1:0 -> ../../sdc lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:1:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:2:0 -> ../../sdd lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:2:0-part1 -> ../../sdd1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:3:0 -> ../../sde lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:3:0-part1 -> ../../sde1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:4:0 -> ../../sdf lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:4:0-part1 -> ../../sdf1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:5:0 -> ../../sdg lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:5:0-part1 -> ../../sdg1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:6:0 -> ../../sdh lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:6:0-part1 -> ../../sdh1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:7:0 -> ../../sdi lrwxrwxrwx 1 root root 10 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:7:0-part1 -> ../../sdi1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:8:0 -> ../../sdj lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:8:0-part1 -> ../../sdj1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:03:00.0-scsi-0:0:9:0 -> ../../sdk lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:03:00.0-scsi-0:0:9:0-part1 -> ../../sdk1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy24-lun-0 -> ../../sdo lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy24-lun-0-part1 -> ../../sdo1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy25-lun-0 -> ../../sdp lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy25-lun-0-part1 -> ../../sdp1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy26-lun-0 -> ../../sdq lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy26-lun-0-part1 -> ../../sdq1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy27-lun-0 -> ../../sdr lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy27-lun-0-part1 -> ../../sdr1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy28-lun-0 -> ../../sds lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy28-lun-0-part1 -> ../../sds1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy29-lun-0 -> ../../sdt lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy29-lun-0-part1 -> ../../sdt1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy30-lun-0 -> ../../sdu lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy30-lun-0-part1 -> ../../sdu1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy31-lun-0 -> ../../sdv lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy31-lun-0-part1 -> ../../sdv1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy32-lun-0 -> ../../sdw lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy32-lun-0-part1 -> ../../sdw1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy33-lun-0 -> ../../sdx lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy33-lun-0-part1 -> ../../sdx1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy34-lun-0 -> ../../sdy lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy34-lun-0-part1 -> ../../sdy1 lrwxrwxrwx 1 root root 9 Feb 18 17:10 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy35-lun-0 -> ../../sdz lrwxrwxrwx 1 root root 10 Feb 18 17:11 pci-0000:84:00.0-sas-exp0x500c04f2715fe43f-phy35-lun-0-part1 -> ../../sdz1 Quote Link to comment
doron Posted February 24 Author Share Posted February 24 Thanks @Elmojo . One further question: which are the zfs devices?Re the SMART thing, this is in fact a *result* of the drive being spun up, rather than the cause, so, no...Sent from my tracking device using Tapatalk Quote Link to comment
Elmojo Posted February 24 Share Posted February 24 (edited) 38 minutes ago, doron said: Thanks @Elmojo . One further question: which are the zfs devices? Re the SMART thing, this is in fact a *result* of the drive being spun up, rather than the cause, so, no... Sent from my tracking device using Tapatalk SDJ-SDN are the ZFS pool that won't seem to stay down. SDO-SDZ are also a ZFS pool, but those are in an external enclosure, and oddly seem to be working fine. The difference, I think, is that the first pool are Seagate drives. Bummer about the SMART, I thought I had it figured out... lol Here's the whole rundown, if that helps... Edited February 24 by Elmojo added screenshots Quote Link to comment
doron Posted February 24 Author Share Posted February 24 @Elmojo, from looking at your data, it does seem that your internal ZFS pool (the one we're discussing) is in fact being accessed a short while after being spun down. You can see that the "SMART read" messages (a great indication of a drive being spun up) show up about 1-2 minutes after the respective spin down messages. This, in most cases, indicates some sort of disk activity. The question whether the drive in fact spins down can be answered as follows: 1. Open both a UI and a CLI terminal window, have both ready 2. Push the UI button to spin the drive down, after noting its dev name 3. Immediately thereafter (don't wait too long), issue, on the CLI terminal, this command: sdparm -C sense /dev/sdX replace sdX with the actual device name. If the drive is spun down, you will see the word "standby" somewhere on the sense data. Quote Link to comment
Elmojo Posted February 24 Share Posted February 24 58 minutes ago, doron said: If the drive is spun down, you will see the word "standby" somewhere on the sense data. Indeed. root@Tower:~# sdparm -C sense /dev/sdn /dev/sdn: SEAGATE ST6000NM0014 MB84 Additional sense: Standby condition activated by command They spin down, but you see in the attached screen that sdj, sdk and sdn have already spun right back up! Quote Link to comment
doron Posted February 24 Author Share Posted February 24 @Elmojo right, yet it does sometimes take it around two minutes until it spins back up. So, probably activity.Sent from my tracking device using Tapatalk Quote Link to comment
Elmojo Posted February 24 Share Posted February 24 46 minutes ago, doron said: So, probably activity How do I go about tracking down what that activity might be? Is there a tracer app that will tell me what processes access which devices? If so, that sounds like it might be something a little beyond my abilities to interpret... lol Quote Link to comment
Toibs Posted February 29 Share Posted February 29 @doron So my devices hapilly spin down manually and stay down for a while before coming back up. However they never spin down automatically. If i manually spindown from the Main screen, i see this in the logs : Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdh Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdg Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdd Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sde Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdb Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdf Feb 29 00:48:38 Kermit emhttpd: spinning down /dev/sdc Feb 29 00:48:38 Kermit SAS Assist v2024.02.18: Spinning down device /dev/sdd Feb 29 00:48:38 Kermit SAS Assist v2024.02.18: Spinning down device /dev/sde Feb 29 00:48:38 Kermit SAS Assist v2024.02.18: Spinning down device /dev/sdc Feb 29 00:48:38 Kermit SAS Assist v2024.02.18: Spinning down device /dev/sdf Feb 29 00:48:38 Kermit SAS Assist v2024.02.18: Spinning down device /dev/sdb However cannot see any attempts to automatically spin down - only when done manually. I am using ST6000NM0034 Drives on a Dell RX730. Bit of a newbie here - Any suggestions as to what I can try?? Many thanks! Quote Link to comment
Elmojo Posted February 29 Share Posted February 29 1 hour ago, Toibs said: Any suggestions as to what I can try?? Read back through the past couple pages at least. You appear to be having the exact same issue as me. Hopefully someone will jump in to help us. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.