Lev

Members
  • Posts

    357
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Lev

  1. 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.
  2. @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.
  3. 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.
  4. 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.
  5. 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.
  6. @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.
  7. 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=2CHHA9LP SAS drive E: ID_SCSI_SERIAL=ZLW0XV610000C0348ZZZ E: ID_SERIAL=35000c500ca42e0ab <-- this is not the serial number E: ID_SERIAL_SHORT=5000c500ca42e0ab
  8. @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.
  9. 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.
  10. 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?
  11. Not sure what explains this being fixed, but good new is good news... first time in many versions I'm able to run the UnRAID GUI. I tested both legacy and EFI boot modes and both now work. Awesome, I very much missed this feature! ๐Ÿ˜ƒ Everytime I boot into the GUI, after login, Firefox has a message pop-up asking to be the default browser, and select a color theme. If there is a way to make these selections persist, so not prompted after each reboot, that would be make the user experience that much more elegant.
  12. 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 !
  13. Makes sense. Nevermind my suggestion.
  14. Upgrading both the 846 and 826 backplanes to SAS3. Such an easy swap in Supermicro 847 case. @johnnie.black 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.
  15. Huge improvement =D Night and day difference for me. Like wow! LIKE WOW!
  16. You made a lot of great points. And you're right, there is likely a better way I could structure things that would reduce the number of UDs.
  17. Super helpful response @Squid, thanks for the details.
  18. UD animation and it can vary in length of time. Fastest is usually 5-6 seconds, average maybe around 8 - 10 and the extreme would be 15-20 seconds. The UnRAID main page loads instantly.
  19. No smb / nfs mounts are in use or created. I think I also keep the disks spun up to see if that helps. Sometimes it's a longer wait for the refresh than other times. I suspect this is when there is activity on one or more of the drives and UD is having to wait in the queue to get the info from the disks that it needs for the refresh. You rock, awesome.
  20. Story time.... ๐Ÿคฃ I think I have a lot of UDs. 16 drives to be exact managed by UD. Pretty cool! Quite the growth since 2011 when I first started with UnRAID. I have all 28 data disks in UnRAID utilized. So now with another 16 disks managed by UD, it'd given me some experiences to consider how UD works with this managing this many devices and where do I want to go next. The recent enhancement of 'None' or 'All' to show the mount points has been awesome. Really improved the usability of UD with this many devices. I can easily find mount point names. As I keep adding devices, managing mount point names is getting more of a chore. Thankfully UD has a great feature that it uses the disk serial number ID by default as a mount point. This works great with MergerFS, as I can keep this default, and just add the parent directories I wish on the drive and MergerFS takes care of the rest. Super easy! ๐Ÿ˜€ Two enhancements I think about sometimes based on this large number of UD devices: 1With this many devices in UD, it can take about 10 or more seconds to load the Main UnRAID page with the UD GUI. It has me wondering if there is a way to speed this up. Like if disabling temperature (hdparm) or some other info UD queries to improve UD loading speed. I find of all the switched on the UD GUI I use the 'Auto-Mount' switch the most. Each time it triggers the 'refresh animation' and has me wondering if there is a way to make it work similar to UnRAID Docker's 'autostart'. Those switches don't trigger a GUI refresh when switched, so I'm wondering if a similar method could be leveraged by UD. I really love UD has enabled all this to be possible via the GUI. While I could do it via the console, it wouldn't be as much fun. Really appreciate all the work you've put into UD over the years @dlandon.
  21. Need some help wrapping my head around the XFS option. Here's what I *think* I know, if someone can correct or affirm, I'd appreciate it ๐Ÿ˜€ Let's play True or False.... brtfs has traditionally been the cache drive file system of preference if using Docker. T/F ? brtfs was the preference because it supported Copy on Write COW, which was helpful for de-duplication of Docker images. T / F ? XFS with the new-ish (2018?) reflink=1 that is now the default format option for XFS in UnRAID also enables COW. T / F ? Moving forward I can now select XFS as my cache drive option where Docker images are stored. Or the new Docker folder is pointed @Squid and can gain all the benefits I had before using brtfs but with the trust and stability that XFS brings. T / F ? Thanks for playing!
  22. This is correct. UnRAID's starting sector is 64, it used to be 63. Never 2048. I know it sucks to hear. But consider it a good excuse to buy one more Easystore to shuck and make the long copy process a little less painful ๐Ÿ˜€
  23. I've been puzzled for the last week why most of my XFS partitions were reporting 'sectsz=512' and a few were reporting 'sectsz=4096' and traced it to a whether the drive had been partitioned and formated by UnRAID or UnAssigned Devices. I put the detailed log output at the very bottom to show both outputs. Researching if an answer existed already I had to take a trip down memory lane searching through the posts to recall that UD didn't always create UnRAID compatible partitions. I remember those days but didn't find an answers to why the difference. I went deeper into the code and traced it to the difference in the following commands: # Create new UnRAID Partition sgdisk -o -a 8 -n 1:32K:0 {$dev} # Create UnAssigned Disk Partition sgdisk -o -a 1 -n 1:32K:0 {$dev} What's the real impact? ๐Ÿคทโ€โ™‚๏ธ Both ways work and are functional, however the UnRAID command aligning on "-a 8" does seem to not trigger an alignment warning. # UnRAID partition creation # sgdisk -Z /dev/sde GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. # sgdisk -o -a 8 -n 1:32K:0 /dev/sde Creating new GPT entries in memory. The operation has completed successfully. # UnAssigned Devices partition creation # sgdisk -Z /dev/sde GPT data structures destroyed! You may now partition the disk using fdisk or other utilities. # sgdisk -o -a 1 -n 1:32K:0 /dev/sde Creating new GPT entries in memory. Warning: Setting alignment to a value that does not match the disk's physical block size! Performance degradation may result! Physical block size = 4096 Logical block size = 512 Optimal alignment = 8 or multiples thereof. The operation has completed successfully. Detailed XFS_INFO output from two drives for comparison Partitioned and Formated by UnRAID v6.8.3 # xfs_info /dev/sde1 meta-data=/dev/sde1 isize=512 agcount=11, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=2929721331, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Partitioned and Formated by UnAssigned Devices v2020.06.28 # xfs_info /dev/sdas1 meta-data=/dev/sdas1 isize=512 agcount=8, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 data = bsize=4096 blocks=1953506633, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Any thoughts on this @dlandon ?