January 20Jan 20 Can anyone help me understand why an array might think a disk is "missing", when it is most certainly not?i.e. I can mount the partition of the "missing" disk and see all the files.... but I can't re-add the disk to the array because it does not show up in the "add disk" dropdown after creating a "new config".I think it likely has something to do with the unassigned devices plugin*, but I even removed that completely and still don't have the option to re-add my disk to the array because it never shows up in that dropdown as eligible to add.Is there some easy way to get a disk that unraid thinks is ineligible to be added to the array for some reason to be eligible again?I was messing with this plugin because it seems like all of my drives have been duplicated for some reason, likely to do with the UUIDs changing (SAS drives...).In short, I have drives with two drive labels i.e. /dev/sdk and /dev/sdae for example, both point to the same physical drive. I verified this by mounting one, touching a new file, unmounting it, mounting the other and voila.... magically the file exists on both. This seems like a bug or, at least, terrible design to be able to create such a dangerous state..... anyone else seen this behavior?
January 20Jan 20 Community Expert Solution Make sure there's only one cable connected from the HBA to the NetApp enclosure; Unraid doesn't support dual path, then reboot and post new diags.
January 20Jan 20 Author Wow... you're kidding. That is extremely disappointing. Not that multipath is not fully supported.... but that THIS is how I had to find out, which is too little, too late, unfortunately. wow.I can almost understand the argument if the developers did not want to invest the time and effort to FULLY support linux-multipath, even though it would not be too hard to implement (Yes, I am a developer too, so I have an idea what it would take) and despite the fact that it would be a huge boon to redundancy / reliability for your customers.... (which I would think would be fairly high priority since the product is for STORING DATA....) almost.... because it is a "new feature" and would "take effort to develope and thoroughly test and not benefit a huge percentage of the existing users", etc.... I get the argument against full support. I don't like or agree with it, but I understand it....But to be aware of this type of hardware configuration, and the confusing and dangerous situation this type of setup causes for the end users.... and to knowingly ignore the high probability for catastrophic data loss is just wrong.It would take an absolutely minimal amount of effort to simply identify this hardware configuration, when encountered, and then either:A. put in some SIMPLE safety measures to prevent the highly-likely situation that would ultimately result in lost data or (if that miniscule amount of work is too much to ask....then)B. AT THE VERY LEAST WARN THE USER of the situation so they can avoid making the type of mistakes that WILL result in catastrophic data loss.Put another way, this (multipath, and how UNRAID handles it, or doesn't, I should say) is not "an unsupported feature" ... it is POTENTIAL LANDMINE FOR USERS' DATA and the argument is, what.... putting up a "don't play in the minefield, no lifeguard on duty!" SIGN is too much to expect???I am completely shocked by this.... and extremely disappointed. I can say, for absolute certainty, this is worth (at the absolute minimum) a big, glaring WARNING to the end-user about the potential for data loss with this kind of setup, and UNRAIDs complete lack of support for it (or even the most basic safety measures) since I literally just blew away a full drive worth of data before realizing something was wrong with the sandbox I was playing in. A sign warning of the potential danger I was walking into sure would have been nice a few hours ago. Edited January 20Jan 20 by infinisean
January 20Jan 20 Author To be clear, my frustration is not aimed at you.... thank you for providing the info I needed. I just wish it had been posted along the way by the folks making money from this software, as that would have saved me from making a catastrophic mistake....
January 20Jan 20 Community Expert Multipath not working should not result in any data loss; it typically results in not being able to correctly assign/configure devices, personally I've never seen a user lose data because of this.I've seen users losing data because of badly configured multipath with other OSes. Even TrueNAS, which supported this in the past, ended support some time ago: https://www.truenas.com/community/threads/sas-multipath-support-on-truenas-scale-22-12-x.110847/#post-766745
January 20Jan 20 Author I didn't say multipath not working caused data loss.... I said it led me to make a catastrophic mistake, which did involve (re)assigning/configuring a device I did not realize was already in use, since I was working with, what I now know was the second drive label that pointed to a drive that was already active. it was my mistake and I don't deny that.... but like I said, knowing a specific type of hardware configuration** can lead to a confusing / non-obvious, yet dangerous situation where drives have more than one label.... is likely going to cause this kind of issue for more and more people..... so a simple warning (at least) would go a long way toward preventing the kind of easy-to-make mistake that just cost me a drive full of data.** (especially one that will get more and more common, with the falling prices of older, enterprise gear hitting the secondary market)
January 20Jan 20 Author A simple warning telling me "Hey, you are trying to configure /dev/sdXX, but that is the secondary path for an existing drive, /dev/sdYY" would have been more than enough to stop me dead in my tracks before shooting myself in the foot.
January 20Jan 20 Author Just so you can see what I'm talking about.... I just wrote a quick python script to identify disks which have a second label (path) and this is what my system's drive layout looks like:================================================================================DISK IDENTIFIERS:================================================================================ID: 091984A5-894A-4149-8C76-EB76D0307C05 /dev/sdfID: 0x02f9b43f /dev/sdaID: 0x2606f38e /dev/sdar /dev/sdxID: 0x31fa891f /dev/sddID: 0x4799d707 /dev/sdat /dev/sdzID: 0x4db6dd20 /dev/sdac /dev/sdiID: 0x5bb3e942 /dev/sdah /dev/sdnID: 0x6db3ca47 /dev/sdaq /dev/sdwID: 0x7d892521 /dev/sdas /dev/sdyID: 0x8e56b73a /dev/sdak /dev/sdqID: 0x9c919155 /dev/sdab /dev/sdavID: 0xa1f333fa /dev/sdaa /dev/sdauID: 0xa9ca1b56 /dev/sdawID: 0xbae43e04 /dev/sdaj /dev/sdpID: 0xbe66a7e1 /dev/sdad /dev/sdjID: 0xc525762d /dev/sdae /dev/sdkID: 0xc75a5444 /dev/sdaf /dev/sdlID: 0xccd7694d /dev/sdal /dev/sdrID: 0xd016fa22 /dev/sdao /dev/sduID: 0xd0a13972 /dev/sdcID: 0xdba59f85 /dev/sdaxID: 167DDCDA-18F3-456D-B654-4D319BEF5BB1 /dev/sdeID: 5C11EE0D-8018-4099-8281-50E24D051BE1 /dev/sdan /dev/sdtID: 682700EB-7283-4A63-BAF2-14FFFA71559E /dev/sdba /dev/sdbbID: 74B85AF7-2A28-4CC5-AEA5-91AD7D348BE1 /dev/sdap /dev/sdvID: 8ADB5984-A77A-4408-9E98-82BC327883E4 /dev/sdai /dev/sdoID: 8ED2AB6D-FA1C-4224-B6A5-6D927EA2F312 /dev/sdhID: 9D72CD99-EC5E-4B58-8C5F-C4E1213C4FB0 /dev/sdag /dev/sdmID: 9F199BA4-EA66-4023-8F4F-99CCCAD38434 /dev/sday /dev/sdazID: D3752B9F-BBEB-4544-89C9-EA6932B4C3D8 /dev/sdam /dev/sdsID: DC74CB27-230D-496A-9491-8FF2FE77D840 /dev/sdgID: EEB8A91D-1C8C-415A-BC19-2A3413A6B5D4 /dev/sdbI wrote that in 5 minutes, which is about how much effort it would take for UNRAID to identify this kind of scenario and warn against the potential danger of treating a secondary drive label/path as if it were another, unused drive.
January 20Jan 20 Community Expert 18 minutes ago, infinisean said:I didn't say multipath not working caused data loss.... I said it led me to make a catastrophic mistakeRoger, misunderstood.18 minutes ago, infinisean said:A simple warning telling me "Hey, you are trying to configure /dev/sdXX, but that is the secondary path for an existing drive, /dev/sdYY" would have been more than enough to stop me dead in my tracks before shooting myself in the foot.Yeah, that should be doable, though I'm not sure if they would need the hardware to reproduce, but it would be helpful for other users. It's not a very common thing, but it's certainly not the first time it came up.
January 20Jan 20 Author They wouldn't need hardware to reproduce.... I just laid out exactly how to do it in like 120 lines of code.1. Loop through all /dev/sdXXX (alpha only, no partitions) and get the device identifier string for each one.2. loop through the list of identifiers and search for all labels that have each one.... now you have a list of identifiers with their corresponding labels (paths). Any IDs that have more than one, treat with caution / warnings.I'd be happy to beta test for them with the actual hardware, if they want. or provide them the simple check script I wrote, that they can use as a starting point. Hell, it would be very simple to actually put safeguards in place to where the user would not even be able to make this kind of mistake if they tried. i.e. once labelA (tied to ID-X) is put in-use, make it impossible to configure anything with labelB (tied to the same ID-X) and voila.... no more cat-tastrophies. Edited January 20Jan 20 by infinisean
January 20Jan 20 Author GitHubunraid_tools/multipath_check.py at main · infinisean/unra...Contribute to infinisean/unraid_tools development by creating an account on GitHub.140 lines, I stand corrected.
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.