dlandon

I'm not sure what UD is doing to format the drive in ntfs. I'll do some research and see if I can understand it.

Mounting a btrfs pool would be beyond the scope of what I feel is the goal of UD. I would think this capability might be better served if LT were to incorporate the functionality into unraid. I see that what is being requested is the ability to set up a btrfs pool and mount/unmount the pool on startup/shutdown and not the array starting and stopping. I believe there are some issues with starting and stopping Dockers and VMs that need to be handled by unraid, and not the UD plugin.

I've swung again (sat here over my coffee before I get into mid month project finance reviews) and I'm sharing RobJ's view which brings me back to this excellent plugin which of course I am currently using. So, long story short (I know - too late ) - do you think Unassigned Devices could be developed to manage a btrfs array? Would LT allow for the stripped down version (as RobJ referred to it) of the Cache Pool code to make its way into this Plugin? Just thinking out loud .... It does appear that this was asked in the previous thread here: http://lime-technology.com/forum/index.php?topic=38635.msg376126;topicseen#msg376126 The response (as I interpret it) was that if a btrfs pool is set up prior and one of the disks is mounted then the entire pool is mounted. So far it appears it is untested as this is where the discussion appeared to end. I'm not sure it would be appropriate for me to butt into the conversation you seem to be having with yourself.

SSDs SDB SDD SDE SDF All 4 were showing grey icon and asterix for temp. This post will show you how to stop the spin down http://lime-technology.com/forum/index.php?topic=45807.msg440420#msg440420

Which one is the UD device that is showing spun down and no temperature?

Nope, there is an asterix where the temp usually is. Is there a way to disable standby or increase from 15mins to something like 180mins? Go to a command line and give the output of the following commands: smartctl -A -d sat,12 /dev/sdx hdparm -C /dev/sdx Where sdx is the device.

The default script will enable the drive standby check and temperature display, but the drive can still go into standby mode in 15 minutes. Does the temperature of the SSD show?

The drives have never been written to when mounted on the unraid server. They contain data written by a windows machine. They are only being read through the unassinged devices share. How do I now they spin up - 1) I am standing right next to the unraid server and can see/hear/feel them spinning up one after another (its seven drives so it takes quite a while - and none of additonal 5 array drives spin up) 2) changing tabs on the unraid gui is not possible while the 7 unassinged devices drives spin up. Also it might not be specific unassinged devices code that leads to the drives being spun up - maybe its unraid core code (maybe a change in 6.1.7 or 6.1.. Interestingly sometimes they do not spin up - i have a "feeling" it only happens under certain conditions, maybe the first time you log into the gui. It's no biggie, but kind of annoying to wake up seven drives for no reason that are perfectly happy being spun down. Also the disks contain the typical windows bitlocker partition structure - so there is a small partition that is not mountable and the main partition (plain non encrypted ntfs) that gets mounted. But I do not know how or if this has anything to do with the behavior. UD does not do any checking of the drive status unless you browse to the UD page. It is not doing any drive monitoring in the background. unraid does not monitor or check any UD mounted drives. Drives spinning up when going to the main unraid tab is probably something else. If you are using cache_dirs, any disk mounted by UD will be included as a scanned directory unless specifically excluded, or not included. Cache_dirs will scan disks one at a time as you describe. I've also seen when cache_dirs does not have enough memory, it will have to un-cache and re-cache directories. You might try excluding the seven drives in cache_dirs you have mounted with UD.

ls /dev/disk/by-id: root@media01:~# ls /dev/disk/by-id/ ata-MKNSSDCR480GB-G2_MK151112AS2215611@ scsi-ST8000AS0002-1NA_Z84030D2-part1@ ata-MKNSSDCR480GB-G2_MK151112AS2215611-part1@ scsi-ST8000AS0002-1NA_Z8405313@ ata-OCZ-TRION100_952B54S2KMCX@ scsi-ST8000AS0002-1NA_Z8405313-part1@ ata-OCZ-TRION100_952B54S2KMCX-part1@ scsi-WD30EFRX-68AX9N0_WD-WMC1T3481101@ scsi-ARC-1231-VOL#06_0000003895606702@ scsi-WD30EFRX-68AX9N0_WD-WMC1T3481101-part1@ scsi-ARC-1231-VOL_00_0000003274592794@ scsi-WD5000HHTZ-04N21_WD-WX61E62L3287@ scsi-ARC-1231-VOL_00_0000003274592794-part1@ scsi-WD5000HHTZ-04N21_WD-WX61E62L3287-part1@ scsi-SATA_MKNSSDCR480GB-GMK151112AS2215611@ usb-MUSHKIN_MKNUFDAM16GB_070B4262D199D096-0:0@ scsi-SATA_MKNSSDCR480GB-GMK151112AS2215611-part1@ usb-MUSHKIN_MKNUFDAM16GB_070B4262D199D096-0:0-part1@ scsi-SATA_OCZ-TRION100_952B54S2KMCX@ wwn-0x58889141000739ff@ scsi-SATA_OCZ-TRION100_952B54S2KMCX-part1@ wwn-0x58889141000739ff-part1@ scsi-ST8000AS0002-1NA_Z8402DA1@ wwn-0x5e83a972002b8d00@ scsi-ST8000AS0002-1NA_Z8402DA1-part1@ wwn-0x5e83a972002b8d00-part1@ scsi-ST8000AS0002-1NA_Z84030D2@ And disks.ini: ["parity"] idx="0" name="parity" device="sdb" id="ARC-1231-VOL_00_0000003274592794" rotational="1" size="7814036428" status="DISK_OK" temp="*" numReads="694304" numWrites="545097" numErrors="0" format="GPT: 4K-aligned" type="Parity" comment="" color="green-on" exportable="no" fsStatus="-" fsColor="grey-off" spindownDelay="-1" spinupGroup="host1" deviceSb="" idSb="ARC-1231-VOL_00_0000003274592794" sizeSb="7814036428" ["disk1"] idx="1" name="disk1" device="sde" id="ST8000AS0002-1NA_Z84030D2" rotational="1" size="7814026532" status="DISK_OK" temp="*" numReads="13018140" numWrites="85082" numErrors="0" format="GPT: 4K-aligned" type="Data" comment="" color="green-on" exportable="no" fsStatus="Mounted" fsColor="green-on" fsError="" fsType="xfs" fsSize="7811939620" fsFree="487010472" spindownDelay="-1" spinupGroup="host1" deviceSb="md1" idSb="ST8000AS0002-1NA_Z84030D2" sizeSb="7814026532" ["disk2"] idx="2" name="disk2" device="sdf" id="ST8000AS0002-1NA_Z8405313" rotational="1" size="7814026532" status="DISK_OK" temp="*" numReads="16001758" numWrites="450315" numErrors="0" format="GPT: 4K-aligned" type="Data" comment="" color="green-on" exportable="no" fsStatus="Mounted" fsColor="green-on" fsError="" fsType="xfs" fsSize="7811939620" fsFree="836276820" spindownDelay="-1" spinupGroup="host1" deviceSb="md2" idSb="ST8000AS0002-1NA_Z8405313" sizeSb="7814026532" ["disk3"] idx="3" name="disk3" device="sdg" id="ST8000AS0002-1NA_Z8402DA1" rotational="1" size="7814026532" status="DISK_OK" temp="*" numReads="12613446" numWrites="14560" numErrors="0" format="GPT: 4K-aligned" type="Data" comment="" color="green-on" exportable="no" fsStatus="Mounted" fsColor="green-on" fsError="" fsType="xfs" fsSize="7811939620" fsFree="773954064" spindownDelay="-1" spinupGroup="host1" deviceSb="md3" idSb="ST8000AS0002-1NA_Z8402DA1" sizeSb="7814026532" ["disk4"] idx="4" name="disk4" device="sdc" id="WD30EFRX-68AX9N0_WD-WMC1T3481101" rotational="1" size="2930266532" status="DISK_OK" temp="*" numReads="2414973" numWrites="4608" numErrors="0" format="GPT: 4K-aligned" type="Data" comment="" color="green-on" exportable="no" fsStatus="Mounted" fsColor="green-on" fsError="" fsType="xfs" fsSize="2928835740" fsFree="963815736" spindownDelay="-1" spinupGroup="host1" deviceSb="md4" idSb="WD30EFRX-68AX9N0_WD-WMC1T3481101" sizeSb="2930266532" ["cache"] idx="24" name="cache" device="sdd" id="WD5000HHTZ-04N21_WD-WX61E62L3287" rotational="1" size="488386552" status="DISK_OK" temp="*" numReads="3816162" numWrites="909037" numErrors="0" format="MBR: 4K-aligned" type="Cache" comment="" color="green-on" exportable="no" fsStatus="Mounted" fsColor="yellow-on" fsError="" fsType="xfs" fsSize="488148084" fsFree="482845092" spindownDelay="-1" spinupGroup="host1" deviceSb="sdd1" idSb="WD5000HHTZ-04N21_WD-WX61E62L3287" sizeSb="488386552" uuid="" ["flash"] idx="25" name="flash" device="sda" id="MKNUFDAM16GB" rotational="0" size="15141472" status="DISK_OK" temp="*" numReads="1838" numWrites="2709" numErrors="0" format="unknown" type="Flash" comment="unRAID Sever OS boot device" color="green-on" exportable="yes" fsStatus="Mounted" fsColor="yellow-on" fsError="" fsType="vfat" fsSize="15133280" fsFree="14926880" I found the problem. It is with a '#' in the device id string. 'scsi-ARC-1231-VOL#06_0000003895606702@' It was causing a failure with a php string function finding the partitions on a device. I'll release a new version this evening with a fix.

The ARC drive is attached to an Areca controller (all my drives are with the exception of the OCZ SSD, which is connected to one of the motherboard ports). It's been in the system for about 4 months or so, without any issues at all. The Areca controllers don't pass drive names for hardware raid drives, just the ARC information. My parity drive (2x4tb WD Red drives) also shows up as an ARC device. I really wish Lime Tech would add more support for the Areca controllers, so they could grab temperature and other smart data (as well as spin up and spin down). I've mentioned it in the past without any response . That drive didn't contain any data currently, so I removed the hardware raid assignment for it (just deleted it, since didnt' contain any data), and the errant text went away. Before the last 2 versions of UD it didn't have that errant text, so I wonder what's changed since then? I'm going to try it on a static pass through of the drive and see if it still does it (not a raid set, since it was a raid set of 1 anyway). With that drive set as pass through, the text also doesn't show up. Apparently it's only when the drive is a raidset from the Areca hardware raid controller. Is this something you may be able to fix, as I was planning on setting up a hardware array of 2 480g SSD's to replace my aging Raptor cache drive, and also set up a 2x240gb SSD Docker drive. I changed the way that UD gets the unraid drives and determines which drives are unassigned to be more robust several versions ago. I have some ideas on why this is happening. In order to troubleshoot this issue, I will need more information so I can try to reproduce the error. If you can get the drive back to producing the error and get the following information from a command line, I'll see what I can do to try to reproduce the error. ls /dev/disk/by-id Also post the /usr/local/emhttp/state/disks.ini file. These two pieces of information should help me troubleshoot.

I have come up with an answer for a card reader without a device plugged in. UD will now show 'Insert' instead of 'Format' when a device is not plugged in. 'Mount', 'Format', etc will still be the same. I'll release a new version later today once I do a bit more testing. Thanks dlandon! I can confirm it correctly identifies my card readers, very cool. Umm... would you be open to hiding the preclear links too? I don't see those with the card reader I have. Let me see what I can do. EDIT: Ok, I see where the preclear icon comes from - the pre-clear plugin. I have it fixed.

I have come up with an answer for a card reader without a device plugged in. UD will now show 'Insert' instead of 'Format' when a device is not plugged in. 'Mount', 'Format', etc will still be the same. I'll release a new version later today once I do a bit more testing.

I doubt this because: 1) Nothing has been being written to these disks - EVER 2) All mounted (unassigned devices) disks spin-up (in my case seven 4tb drives) 3) This behaviour is new - and came with the dlandon version of the plugin I believe it has something to do with the way the temp/spin-up status is checked to display it on the "main" page (you do not even need to activate the unassinged devices sub-tab). It should not check if the disks are spun-down - but it does check something (this is all in tabbed gui-mode - do not know what happens in non-tabbed view) Just going to the main page will not cause any UD code to be executed. i.e check drive standby status and temperature. How do you know they are being spun up when browsing to the main page? You say the drives have never been written to but are mounted in UD? Why are you doing that?

The error messages in the install of the plugin come from the command issued to mount all auto mounted devices. It is a php script. That's why the error messages are php errors. Part of that process is to determine what disks are in the array and which ones are outside the array and are unassigned. That's where the error messages are occurring in the script. What is the ARC device? I think it might be related to that.

Download your UD log and post it. Click 'Help' and you'll see the 'Download' log button. There is something unique about your setup that is causing this error. I cannot reproduce this and I see no reason for it. The errors don't make any sense. I've tried to break things to create the problem and I can't. Can you uninstall and re-install the plugin? The only thing I can come up with is there is a problem with your installation of the plugin.

Is it License or Licence? Good point... I'm Canadian, eh so I made it <Licence>. Guess that I can support both spellings as I'll probably take some heat for it.... Doesn't matter. Just let us know which one. I'm ok with either one.

Is it License or Licence?

Download your UD log and post it. Click 'Help' and you'll see the 'Download' log button. There is something unique about your setup that is causing this error.

Grey means spun down or on standby and temperatures are unavailable in that state. Since they are SSDs, can I prevent them from spinning down or going to standby? Do you have a script defined? If you create a script file, the drive will be monitored for spin down status and temperature. Read the second post about best practices. No, I do not have a script defined. What would a script look like that allows me to monitor the SMART/Temp even if the SSD is unmounted or in standby? I really do appreciate your guidance with this. thank you. The check is for the existence of a script file. It can be empty or use the default script that really does nothing. Just click on the edit script icon, select the default script, and then save it. This was done because some users want a "hot standby" disk and don't want it checked for spin up status and temperature. The existence of a script file implies that you are going to use the device and want it monitored. A lot of the support questions coming up here can be easily resolved by reading my second post about "best practices" and looking at the UD log file. I realize everyone is in a hurry these days and wants a quick answer, but the first two posts are an easy read and will answer a lot of your questions. If I have not been clear enough, let me know and I will elaborate as needed.

Grey means spun down or on standby and temperatures are unavailable in that state. Since they are SSDs, can I prevent them from spinning down or going to standby? Do you have a script defined? If you create a script file, the drive will be monitored for spin down status and temperature. Read the second post about best practices.

Yes, my docker image is on a device which is automounted by UD. The config folders are on a cache-only share. I didn't go digging very far but either removing UD dismounted the device with the docker image on it, or removing UD messed with some other resource which docker requires. Either way, the advice to not reboot needs to be reconsidered. That's not what I said - I said that one should be cautious if expecting that a reboot is not necessary. Indeed - so, again. dlandon's advice needs to be treated with caution. If you remove the UD plugin, ALL UD mounted devices will be unmounted. That's why you lost the Docker. If you don't stop Docker before you remove UD, then you will be in a situation where a reboot would be required to get Docker going again. In my second post there are some best practices. There is one about unistalling UD: "While this might be quite obvious, you should not uninstall the unassigned devices plugin if you are using a drive for Dockers or VMs. Uninstalling will unmount all mounted drives. If the disk is busy, the unmount will be forced and you will lose access to the disk. Updating the plugin with drives mounted is not an issue at all because they are not unmounted."

I followed this procedure - as soon as I removed the old version of UD, my Docker vanished. There was no Docker tab on the main UI screen, CA told me that Docker was not enabled (I checked Docker settings, and that told me that Docker was enabled), and docker ps returned the following: root@Tower:~# docker ps Get http:///var/run/docker.sock/v1.19/containers/json: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS? After re-installing UD, I rebooted and docker came back. I would suggest that the advice that a reboot is not necessary should be taken with a great degree of caution. In any case, I'm not convinced that the remove/re-install was necessary - it appeared, to me, that the switch from gfjardim's version to dlandon's and already happened automatically, a couple of days ago, when an update was offered to me and it picked up a revision list with 24 entries. At that stage, the author information changed from gfjardim to dlandon. If you have your Docker or VMs on a UD disk, you should stop the Docker and/or VMs before uninstalling UD. A UD update will not be an issue because devices mounted will not be unmounted. One caveat though is that when you update, UD will auto mount any devices set as "auto mount' that aren't already mounted. The update from gfjardim's version to this newer version happened because gfjardim's github was updated with the new version .plg file so the update check now points to my github and the update check installed the updated version. This should help with the confusion over versions and updates will now automatically install the updated UD version.

Are you setting the share switch when the drive is mounted or unmounted? If you are doing it when the drive is mounted, look at the UD log and see if there is anything related to not being able to share the device. When the device is not mounted, the share switch setting will be the setting saved in the configuration. If the device is mounted, UD will attempt to share the device if the share switch is on and if unsuccessful the switch will turn off even if set to on in the configuration settings.

Did this procedure happen to have you uninstall a previous version of UD and install of a newer one?? UD doesn't uninstall cleanly and requires a reboot between installations to work correctly is my understanding. Either way I would recommend this. Uninstall. Reboot. Install. See if the issue is fixed? If you are coming from the gfjardim version to this newer version of UD, you can just remove the older version and then install this version. It does not require a reboot. It does not remove the configuration settings or script files so your settings are saved even if you remove UD. A reboot is not required when updating, or when UD is removed and re-installed. I would add one step to the above. Uninstall UD, then save any scripts you use from the /boot/config/plugins/unassigned.devices. Then delete the /boot/config/plugins/unassigned.devices directory and re-install UD. You will have to reconfigure your settings. It sounds like the configuration file has been corrupted or is out of sync. I will release a new version today that has a setting for whether or not a USB device will auto mount and share. With the setting off, no USB devices will be auto mounted and shared when installed until you make the settings for auto mount, share, or set a script file to run. These settings will then apply when the device is inserted. With the setting on, a USB device will auto mount and share until you make settings for auto mount, share, or set a script file to run.

Yes, it affects USB devices. I thought of that and was waiting for some feedback on whether or not it was important to anyone. The auto mount did cause someone some problems.