Lev
-
Posts
369 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Lev
-
-
7 minutes ago, Andrew Dens said:
root@Gringotts:~# ls /dev/nv*
/dev/nvme0 /dev/nvme0n1 /dev/nvme0n1p1
root@Gringotts:~# zpool import -d /dev/nvme0n1
no pools available to import
root@Gringotts:~# sgdisk -Z /dev/nvme0n1***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.Show me the output of this command. The -n means it will take no action, it'll just output a list of partitions.
wipefs -n /dev/<device>
-
10 minutes ago, Andrew Dens said:
I tried zeroing out the device with preclear UD plugin, no luck. I plugged it into a windows pc and formatted it there as ntfs and then plugged back into unraid and that was able to mount by unassigned devices. Then I unmounted, cleared with UD, then tried to format as XFS/BTRFS and NTFS and it's still grey it won't allow mounting.
This command may clear it, be extra sure you point it at the right device.
sgdisk -Z /dev/<device>
-
6 hours ago, ClintE said:
BTW, this does not happen on an older version of unRAID that I haven't updated yet (think it's 6.7.something), perhaps because the plugins can't update on that old version.
Yes, you're right @ClintE, I have two servers, the 6.11 server exhibits the problem. The older 6.10 server does not.
I upgraded the older 6.10 server to to the current 6.11.5, changed nothing else, now it also exhibit the problem.
This is a good clue @dlandon, it's something with how UnRAID changed between 6.10 and 6.11 that's causing the conflict with UD.
-
@dlandon I can confirm their is some strange behavior with the Friefox browser with UD as @ClintE is reporting. I've been experiencing it for months? and been putting up with it, because I wasn't sure which plug-in was causing it, but finally had some time to look into it more.
First I booted into UnRAID safe mode. Problem did not occur. Then I started uninstalling plug-ins one by one...
When I uninstall UD, starting the array behaves normally. It's only when UD is installed that this problem occurs. This problem does not occur in safe mode.
I tested with MS Edge and cannot reproduce. I don't have Chrome installed to test with.
Here's what it looks like... UD is installed, using Firefox, I start the array... once the array is started and the page refreshes, Firefox prompts me with this. Diagnostics attached.
I must click 'cancel' or else I'm in for a world of hurt, because the GUI will no longer work and I have to ssh to umount everything and reboot.
-
12 hours ago, slimshizn said:
Thought my server just kicked off my UD's. Rebooted ( after a LONG uptime ), still down, came here to check out what's going on.
Went to historical devices, clicked on each disks settings.
Hit saveHit done
Each is back where it's supposed to be.
Cool update.
I had the same experience after updating the UD plugin to the latest version just now. All my UD drives had been moved to history. Thanks for the quick fix you provided, it resolved the situation easily.
-
1
-
-
7 hours ago, dlandon said:
Today's release has a fix for SCSI disks that don't show in UD with the dynamix.scsi.devices plugin installed.
Works! 😃 Thank you @dlandon
-
TL:DRTwo problematic inconsistencies I've found with the naming convention for disk/by-id/scsi-*
Either one or a mix of both maybe the root cause, please check. Supporting research is underneath in how I concluded this.
-
If the _ underscore is being used as a delimiter in UD functions, it does not have strong consistency with SATA and with SCSI there is no consistency in its use in the naming convention for disk/by-id
-
My guess is UD is unaware that the plugin once installed is altering the naming convention of disk/by-id/ specifically for SCSI devices, replacing the expected 'ID_SERIAL' with 'ID_SCSI_SERIAL' as this key is only encountered and present with SCSI disks, not ATA. See UDEVADM output below.
- UnRAID detection in the drop down list is consistent in naming convention 'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!) in both situations, plugin installed or NOT installed, my guess is the UnRAID detection function may have a conditional IF 'ID_BUS' = 'scsi' then use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL' that aligns with how the plugin also uses 'ID_SCSI_SERIAL'for only SCSI disks.
Supporting Research
It was not easy to map the two different ID's for the disk that were generated with the plugin installed and with it removed to make this simple table.
Why? lsscsi and all it's various command options will not output it, it's UDEVADM and some logic code.
Here's what's interesting, and why I'm sharing this... notice the naming convention naming convention is not the same between the SATA drives and the SAS/SCSI drives. In multiple ways.
Pay close attention to the underscores between the keys, I think they are the delimiter and this maybe where some function is expecting one or two delimiters to be present to return the expected values. This inconsistency in naming convention looks like something that could cause some problems like what we are seeing.
SATA disk
disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN
Naming convention: 'ID_BUS'(not Unique)-'ID_SERIAL'(Unique!)
root@tower2:~# udevadm info --query=all --name=/dev/sdg P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:52/1:0:52:0/block/sdg N: sdg S: disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN S: disk/by-id/wwn-0x5000cca29dc2d03d S: disk/by-path/pci-0000:01:00.0-scsi-0:0:52:0 E: DEVLINKS=/dev/disk/by-id/ata-WDC_WD140EDGZ-11B2DA2_3HG65VTN /dev/disk/by-id/wwn-0x5000cca29dc2d03d /dev/disk/by-path/pci-0000:01:00.0-scsi-0:0:52:0 E: DEVNAME=/dev/sdg E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:52/1:0:52:0/block/sdg E: DEVTYPE=disk E: ID_ATA=1 E: ID_ATA_DOWNLOAD_MICROCODE=1 E: ID_ATA_FEATURE_SET_APM=1 E: ID_ATA_FEATURE_SET_APM_ENABLED=0 E: ID_ATA_FEATURE_SET_HPA=1 E: ID_ATA_FEATURE_SET_HPA_ENABLED=1 E: ID_ATA_FEATURE_SET_PM=1 E: ID_ATA_FEATURE_SET_PM_ENABLED=1 E: ID_ATA_FEATURE_SET_PUIS=1 E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY=1 E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0 E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=65538 E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=66774 E: ID_ATA_FEATURE_SET_SMART=1 E: ID_ATA_FEATURE_SET_SMART_ENABLED=1 E: ID_ATA_ROTATION_RATE_RPM=7200 E: ID_ATA_SATA=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1 E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1 E: ID_ATA_WRITE_CACHE=1 E: ID_ATA_WRITE_CACHE_ENABLED=1 E: ID_BUS=ata E: ID_MODEL=WDC_WD140EDGZ-11B2DA2 E: ID_MODEL_ENC=WDC\x20WD140EDGZ-11B2DA2\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 E: ID_PART_TABLE_TYPE=gpt E: ID_PART_TABLE_UUID=b7673fa9-3326-4df7-a432-ef769fc82c7e E: ID_PATH=pci-0000:01:00.0-scsi-0:0:52:0 E: ID_PATH_TAG=pci-0000_01_00_0-scsi-0_0_52_0 E: ID_REVISION=85.00A85 E: ID_SERIAL=WDC_WD140EDGZ-11B2DA2_3HG65VTN E: ID_SERIAL_SHORT=3HG65VTN E: ID_TYPE=disk E: ID_WWN=0x5000cca29dc2d03d E: ID_WWN_WITH_EXTENSION=0x5000cca29dc2d03d E: MAJOR=8 E: MINOR=96 E: SUBSYSTEM=block E: USEC_INITIALIZED=33560058SAS/SCSI disk (Plugin NOT installed)
Full Identifier: ST12000NM002G_ZLW0QFJV0000C0438211_35000c500ca3d8cbf
Naming convention: 'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!)'_'ID_SERIAL'(Unique!)
disk/by-id/scsi-35000c500ca3d8cbf (there's not a single _ delimiter)
Naming convention: 'ID_BUS'(not Unique)-'ID_SERIAL'(Unique!
SAS/SCSI disk (Plugin INSTALLED)
Full Identifier: ST12000NM002G_ZLW0QFJV0000C0438211_35000c500ca3d8cbf
Naming convention: 'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!)_'ID_SERIAL'(Unique!)
disk/by-id/scsi-ST12000NM002G_ZLW0QFJV0000C0438211 (there's one _ delimiter)
'ID_BUS'(not Unique)-'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!)
A few things jump out at me...
disk/by-id/ naming convention is changed by the plugin to use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL'
On a SCSI disk, 'ID_SCSI_SERIAL' is strictly the SCSI serial number integer data type, 'ID_SERIAL' is a data type which appears to a data conversion of the hexidecmal WWN of the disk. See UDEVADM output below for SCSI SAS and then scroll back up to compare against ATA. It's a mess.
Comparing the two UDEVADM outputs you'll notice the ATA device where 'ID_SERIAL' returns a long string data type, with _ underscores as delimiters for 2 other data keys, 'ID_MODEL'_'ID_SERIAL_SHORT' Also 'ID_MODEL' WDC contains a _ delimiter with value returned to complicate things further. Ugh.
root@tower2:~# udevadm info --query=all --name=/dev/sdk P: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:62/1:0:62:0/block/sdk N: sdk S: disk/by-id/scsi-35000c500ca3d8cbf S: disk/by-id/wwn-0x5000c500ca3d8cbf S: disk/by-path/pci-0000:01:00.0-scsi-0:0:62:0 E: DEVLINKS=/dev/disk/by-id/scsi-35000c500ca3d8cbf /dev/disk/by-id/wwn-0x5000c500ca3d8cbf /dev/disk/by-path/pci-0000:01:00.0-scsi-0:0:62:0 E: DEVNAME=/dev/sdk E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host1/target1:0:62/1:0:62:0/block/sdk E: DEVTYPE=disk E: ID_BUS=scsi E: ID_MODEL=ST12000NM002G E: ID_MODEL_ENC=ST12000NM002G\x20\x20\x20 E: ID_PATH=pci-0000:01:00.0-scsi-0:0:62:0 E: ID_PATH_TAG=pci-0000_01_00_0-scsi-0_0_62_0 E: ID_REVISION=E003 E: ID_SCSI=1 E: ID_SCSI_SERIAL=ZLW0QFJV0000C0438211 E: ID_SERIAL=35000c500ca3d8cbf E: ID_SERIAL_SHORT=5000c500ca3d8cbf E: ID_TYPE=disk E: ID_VENDOR=SEAGATE E: ID_VENDOR_ENC=SEAGATE\x20 E: ID_WWN=0x5000c500ca3d8cbf E: ID_WWN_WITH_EXTENSION=0x5000c500ca3d8cbf E: MAJOR=8 E: MINOR=160 E: SUBSYSTEM=block E: USEC_INITIALIZED=33453336
UnRAID detection in the drop down list is consistent in naming convention 'ID_MODEL'(not Unique)_'ID_SCSI_SERIAL'(Unique!) in both situations, see screenshot below, does not matter if plugin installed or NOT installed, it appears as UnRAID has the condition IF 'ID_BUS' = 'scsi' then use 'ID_SCSI_SERIAL' instead of 'ID_SERIAL' is my guess for its detection function.
-
If the _ underscore is being used as a delimiter in UD functions, it does not have strong consistency with SATA and with SCSI there is no consistency in its use in the naming convention for disk/by-id
-
1 hour ago, dlandon said:
@Lev Are you showing the complete 'ls' output? It appears something is missing.
yes. I just ran again, same output confirmed.
ls /dev/disk/by-id -
33 minutes ago, dlandon said:
@Lev I have an idea. Can you show me the results of the command 'ls /dev/disk/by-id'?
EDIT: With the scsi plugin installed.
Here's the output of NOT Installed (left) and Installed (right) and the lines that are different.
There are two things going on in this, I'll start with the most straight forward.
-
Lines 15-18 on the left are lines 23-26 on the right, but out of order. These are four unassigned Seagate SAS disks using JBOD pass-through on a LSI 3108 RAID controller. Below is a table I created showing just these four drives in aligned order to make it less confusing.
Best to focus on any of these four drives, but I'll explain what other more complicated thing going on is, because it may give you a clue, or it may just confuse you. In that case just ignore what I'm about to say.
-
Lines 19-26 on the left are lines 15-22 on the right, but out of order. These are four logical RAID disks on the same LSI 3108 RAID Controller. All four of these disks are 'Assigned' successfully to UnRAID on the left (plugin Not Installed) but on the right are 'UnAssigned' (plug Installed) because it no longer matches what value UnRAID has stored to flag the disk as 'Assigned'. However as you can see UnRAID is able to detect all the SAS and RAID drives as they are visible in the drop down selection list and makes no difference whether the plug-in is installed or not.
screenshot below with dynamix.scsi.device plugin NOT installed. Notice UnRAID assignments and detection is working. UD detection is working.
screenshot below with dynamix.scsi.device plugin INSTALLED... Notice UnRAID no longer sees assigned SAS & RAID disks, however detection of those disks is working. UD detection is NOT working.
-
Lines 15-18 on the left are lines 23-26 on the right, but out of order. These are four unassigned Seagate SAS disks using JBOD pass-through on a LSI 3108 RAID controller. Below is a table I created showing just these four drives in aligned order to make it less confusing.
-
On 1/2/2022 at 5:30 AM, dlandon said:
Applied a fix that should show SCSI disks in UD with the dynamix.scsi.device plugin installed. UD now excludes CD and DVD disks, and accepts all other devices. This was changed from including only sd, hd, and nvme devices. I have no way to test though, so I don't know if this works. Feedback would be appreciated. If you see a device in UD that should not be there, let me know as I may need to exclude it.
Not fixed. Same behavior I observed previously. Soon as I installed dynamix.scsi.device plugin the SAS drives that were showing in UD are no longer detected UD. Attached are two diagnostics. One with the dynamix.scsi.device plugin installed, one without it. Hopefully the difference will stand out.
tower2-diagnostics-20220104-1236-dynamix.scsi.device REMOVED.zip tower2-diagnostics-20220104-1215-dynamix.scsi.device INSTALLED.zip
-
18 hours ago, dlandon said:
Applied a fix that should show SCSI disks in UD with the dynamix.scsi.device plugin installed. UD now excludes CD and DVD disks, and accepts all other devices. This was changed from including only sd, hd, and nvme devices. I have no way to test though, so I don't know if this works. Feedback would be appreciated. If you see a device in UD that should not be there, let me know as I may need to exclude it.
will happily test in the coming days 😃 happy others confirmed this issue after I spent so many hours trying to isolate.
-
13 hours ago, dlandon said:
The iscsi command output in your diagnostics shows many duplicate disk id's. Not sure why some disks were missed by UD. Because you re-formatted the disks, I suspect that the previous controllers formatted them in a way specific to the controller that confused Linux and hence UD.
Did you use UD to reformat the disks?
I used UnRAID to format the Seagate 12TB SAS disks. but I found what other plug-in is causing the issue of the SAS drives not being detected. So it had nothing to do with how the drive was formatted.
The plug-in that is causing the issue for the SAS drives with UD is 'Dynamix SCSI Devices'. I've run this plug-in along with UD for years and never had a issue with SATA drives. But this is my first time with SAS drives, and clearly it's causing some type of confusion. I remove the Dynamix SCSI device plug-in, reboot, and UD detects the SAS drives just fine. If I install the Dynamix SCSI Devices plug-in, the SAS drives in UD immediately disappear from UD.
I've reproduced this on two UnRAID servers now with the SAS drives.
Dynamix SCSI Devices and the reasons I first used it years ago, may no longer be needed with today's 6.10.x version of UnRAID. So I'm going to move forward and no longer use that plug-in and see what happens.
-
@dlandon all has been resolved. I formatted and recreated the UnRAID USB drive, installed only UD plug-in. All SAS drives are detected as expected.
No clue what could of be conflicting in the previous install. I'll slowly add back the other plug-ins and check.
Thanks again for all your help.
-
Another test.
I removed the Areca and disabled the MegaRAID 3108 on the motherboard jumpers.
I installed a LSI 2008 HBA card and connected to a backplane.
The LSI 3008 HBA is still connected to its backplane.
UD cannot detect the Seagate ST12000NM002G drives on either controller. UnRAID can see them.
Definitely something about these hard drives metadata is different than UD is expecting.
-
On 11/19/2021 at 11:15 AM, dlandon said:
It's a little more involved that that. UD collects all the disks by-id into an array. wwn ids are ignored. It then removes any from the array with a device number (hdX, sdX, and nvmeX) that is the same device number as a device in the array - it's assumed to be an array disk. What's left are unassigned disks.
Any duplicates in the by-id are taken as unassigned because each one has a unique device number.
Any that are skipped are assumed in the array if the device number is the same as a disk in the array.
Thanks for the info, this will help as I look deeper at the functions.
I have new information to share, its not what I was expecting...
I was never sure how all this would work out with the 3108 IR mode controller that's embedded in my motherboard. So last week I ordered a 3008 IT mode controller, which is the most widely recommended HBA LSI chipset for SAS3 on UnRAID. It arrived yesterday and I installed it. Firmware has been updated to latest release.
I damn near fell out of my chair when UD exhibited the same behavior in regards to the SAS drives we've been talking about.
Up until now, I had been assuming, and perhaps you have too, that the behavior I'm seeing with UD not detecting the six SAS disks was due to using a unsupported 3108 controller in JBOD pass through mode that must be messing with the how the disks are being reported.
Now I can recreate the same behavior on a HBA.
This is not what I was expecting. My plan was to install the HBA, see UD behaves as expected, detects the SAS drives correctly and then I'd move on from the 3108 and use the 3008 HBA. All I really wanted to was to get confidence in that 3108 controller. I got that, and want to thank you for your help over the last few days.
Now I'd describe this differently...What do you think about this issue now being reproducible on a HBA controller? No RAID controllers involved. Worth your time to dive in and investigate?
If so I'm happy to help provide more logs and run tests for you. I have no data on these drives, and this server is not in operation yet.
-
On 11/19/2021 at 10:07 AM, dlandon said:
UD depends on the id that udev picks up. UD uses the /by-id/ to determine what is in the array and what is unassigned and that becomes the id UD uses.
Right, I'm following. When I look at the include/lib.php code, I don't see why it's not working on it's initial detection of unassigned disks. The serial numbers are unique that the controller is providing.
However the 3108 is returning two /by-id/ when invoking 'udevadm' , the other controllers do not do this.
It's passing through an additional /by-id/wwn- identifier for the drive in addition to the expected /by-id/scsi- .
Is it possible that lib.php is expecting only one /by-id/ to be returned when one of the functions for disk detection invokes the 'udevadm' command and it returns two? Because everything so far that I've seen be detected only has the one /by-id/scsi-* value returned in 'udevadm'
Areca:
disk/by-id/scsi-ST12000NM002G_XV9J0000C0398824
3108:
disk/by-id/scsi-ST12000NM002G_ZLW0XV9J0000C0398824
disk/by-id/wwn-0x5000c500ca42d697
Raw output log files attached.
-
@dlandon Success! LOL... but with a twist! Had a breakthrough this evening in narrowing down why this is behaving as it is. Come with me on this journey 😀
I took a single drive, ZLW0XV9J, its physical serial number on the outside label, picture below that is used to make the following example easier to explain.
- UnRAID can detect it when it's attached to the Areca or MegaRAID 3108 controller.
- UD cannot detect it, after reboot, when attached to the MegaRAID 3108 controller
- UD can detect it, after reboot, when attached to the Areca.
- <the twist is coming!>
- UD can detect it, when hot-swapped after reboot, from the Areca to the MegaRAID 3108 controller!
I can mount it, everything works as expected when the drive is connected to the 3108 after it's been hot-swapped from the Areca.
There's a difference in UD's drive detection code, starting in include/lib.php, between lines 1863 to 1902 is where *I THINK* explains UDs behavior. I hope I don't embarrass myself 🤦♂️ but few dare to read the code, but I do!
I say this because the drive attributes returned from udevadm are different depending which controller the drive is attached too, as you'll see. That initial creation of the array of unassigned devices seems to be the point of deviation.
Attached are the following details.
ZLW0XV9J.jpg - This is a picture I took of the physical drive label for helpful reference point.
SAS disk - Areca.PNG - This is ZLW0XV9J correctly identified in UD when attached to the Areca controller.
SAS disk - 3108hotswappedFromAreca.PNG - This is ZLW0XV9J correctly identified in UD after its been hot-swapped from the Areca controller to the 3108 controller.
3108 drives.PNG - Screenshot from system devices showing that the drive is attached to the 3108 after the hot-swap.
UDseesHotSwappedsasDrive.png - This is the money shot... ZLW0XV9J is visible in UD and UnRaid after it was hot-swapped from the Areca, but it's other 5 siblings (ST1200NM002G) are not visible in UD.
udevadm outputs files - I ran command "udevadm info --query=all --name=/dev/sdab" after each change to document how each controller was reporting the information. 3 .txt. files are attached with how that the output of whats being reported changes.
-
57 minutes ago, dlandon said:
UD has to have unique serial numbers for each disk. Your external drive bays are presenting disks with a common serial number.
Yes.... you're on to something here! lsscsi doesn't show serial numbers... I'm running the command udevadm now and finding some interesting differences in terms of how serial number are being reported between the SATA, SAS and RAID drives with the 3108 controller.
udevadm is showing that the SAS and the RAID volumes have their serial number named as 'ID_SCSI_SERIAL' and the contents of the 'ID_SERIAL' align with what you said. I'm curious to check again on the Areca controller it's putting the serial number in 'ID_SERIAL', if so then that may explain it... I'll test and follow up.
SATA drive
E: ID_SERIAL=WDC_WD140EDGZ-11B2DA2_2CHHA9LP
E: ID_SERIAL_SHORT=2CHHA9LPSAS drive
E: ID_SCSI_SERIAL=ZLW0XV610000C0348ZZZ
E: ID_SERIAL=35000c500ca42e0ab <-- this is not the serial number
E: ID_SERIAL_SHORT=5000c500ca42e0ab -
@dlandon I was curious if I switched back to the Areca controller, would anything in the lsscsi command stand out as a difference? Answer is no, unfortunately, I didn't find anything. But I took some screenshots so you can see how UD with the Areca controller behaves as expected, and same as UnRAID in this test scenario.
Remember all the of the drive locations will have changed since I moved the cables from the 3108 to the Areca, so just look for the six ST12000NM002G in the lists.
Also, this is to be expected but just in case you wonder why the 3 RAID volumes are not in the list. Instead the has the 6 HGST physical drives that were part of the RAID volumes that were created on the 3108. All normal behavior here.
-
On 11/17/2021 at 6:05 AM, dlandon said:
You have sdv assigned to the array as a cache disk. What I suspect is that UD sees all the disks as being the same serial number and since sdv is assigned to the array, UD doesn't recognize sdt and sdu as being unassigned.
Do this and let's see if this is the case. Stop the array. Unassign sdv as a cache drive. Look at the UD page and see if UD sees the disks. If it does, show a screen shot. You can then assign sdv back to the array.
Screenshot attached. Unassigned - Cache Drive.png
Following your thinking, I thought I'd do a 'New Config' and get a screenshot of what appears in UD when there is no array defined. Screenshot Unassigned - New Config attached.
This helped find a new clue... there are six more drives went undetected by UD that I did not previously notice which had been assigned in UnRAID. Drives: sdd, sde, sdf, sdg, sdh, sdi This is visible in the screenshot.
So what's different about these 6 other drives? These six are SAS drives, that are passed thru the 3108 as JBOD drives.... same as the SATA drives also are passed thru the 3108 as JBOD drives. SAS vs SATA is the major difference in disk type. See attached 'lsscsi -g.png' for a picture to help illustrate.
Summary of UD behavior by Controller type:
MegaRAID LSI 3108
- UD only detect SATA drives, passed thru as JBOD with this controller. Not detecting SAS or RAID volumes.
- UnRAID detects all three types of drives as unassigned.
Areca 1883
- UD detects all three types as unassigned.
- UnRAID detects all three types as unassigned.
I'm back to wondering... what is the difference between UD's unassigned disk function in code, vs how UnRAID's function works in code to identify eligible disks the operating system has? For example, I noticed in the 'lsscsi -g.png' the VENDOR attribute is generic as 'ATA' for SATA, but for others it's not generic... SAS its 'SEAGATE' and for RAID its AVAGO.
-
Hi @dlandon I'm using a MegaRAID 3108 adapter that I haven't used previously and it's behaving a bit different than my Areca RAID adapter in UD. I'm trying to understand why... mostly just because I want to have confidence in using the 3108 going forward.
First what is working... UnRAID detects and I can assign to array.the 3108 three RAID logical volume drives: sdt, sdu, sdv
When unassigned, the three logical drives don't appear in the UD list.
Any thoughts what it is about how these logical drives are defined that prevent UD from listing them?
-
2 hours ago, dlandon said:
A "Show Partitions" switch has been added to set showing all partitions by specific hard drive device and not generically as before. The option to show all partitions has been removed from the UD Settings.
Perfect, I was wondering where this went, thanks for the explainer. I got it figured out.
Early first impression after 2 minutes of use... I like it! Positive enhancements, thank you @dlandon !
-
On 4/27/2019 at 2:04 PM, Lev said:
@johnnie.black this is a tremendous resource and was interested in your thoughts on what would be the expected speeds to determine the optimal configuration for a for 30+ drives in the following configuration:
SuperMicro SuperStorage 6047R-E1R36L configured as:
- BPN-SAS2-846EL1 (front 24 bays) with three 8087 connectors
- BPN-SAS2-826EL1 (rear 12 bays) with two 8087 connectors
- LSI 2308 SAS2 PCIe 3.0 host adapter with two 8087 connectors (motherboard integrated)
- 6x SATA ports on the motherboard, running at 6GB SATA3 (DMI 2.0)
- 2x NVMe slots via Supermicro AOC-SLG3-2M2 add-in card
- The drives are all WD Red/White 10TB & 8TB models
Unraid setup as of 4/27/2019:
-
Data disks x28
- x24 connected to BPN-SAS2-846EL1 dual linked to LSI 2308
- x4 connected to motherboard SATA ports
-
Parity disk
- x1 disk connected to motherboard SATA port
-
cache disk
- x1 NVMe drive connected to AOC-SLG-2M2
-
Not in use/connected
- BPN-SAS2-826EL1 (rear 12 bays)
- x1 SATA port
- x1 NVMe port
Is this the most optimal setup to spread out the utilization and not encounter bottlenecks? Any opportunities for improvement?
If I was to daisy chain a single link from the third 8087 connector on the BPN-SAS2-846EL1 to the downstream BPN-SAS2-826EL1 how much of a negative impact on performance would that have? The 826-EL1 would be empty, no disks. Would that reduce PHYs available or add significant additional SAS overhead?
Upgrading both the 846 and 826 backplanes to SAS3. Such an easy swap in Supermicro 847 case.
This has been such a helpful resource, and I stumbled across your posts over on another message board about your benchmarks with sas3 that were helpful in knowing what performance to expect with sas3 and databolt. I wanted to post here to say thanks for that. Also if there was anything you wanted to update in your first post here to reflect your most up to date findings.
I'll post some pics of the backplane swap when I get a chance. It's been fun.
-
13 hours ago, dlandon said:
In the latest release of UD, I've tried to do a few things to help with the UI response time.
Huge improvement =D Night and day difference for me. Like wow!
LIKE WOW!
-
1
-
Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array
in Plugin Support
Posted
I'm out of things to suggest to try in UnRAID. Does it the drive still work and partition OK in Windows?
Last option I'd try in Windows is using whatever app Crucial has to wipe the drive and make sure it's got the latest firmware update.
Good luck to you.