@Brett_Abela Thanks for the info. From:
We see each of the 3 drives in the Orico enclosure has a by-id name, which is part of the problem sorted (no serial devices get no by-id name at all), but what we now need to know is if those names are assigned on a first come first served basis, which may change from one boot to the next, or as I am hoping, on a bay/enclosure-slot basis. Can you see if you can establish this? Ie you have 2 different models of drive there and given the enclosure rather unhelpfully obfuscates the actual serials we can’t tell the difference by name alone from the 2 similar models (the essence of why serials are relied upon in Rockstor and by udev). If you can establish that a bay in that enclosure always get the same number assigned to it, ie the “0:0”, “0:1”, “0:2” bit at the end assigned by udev to it’s “ID_SERIAL” element (and in turn used in the generated by-id name, then we have a chance.
So Rockstor can usually track a drive across various different connection methods because it uses the serial, baring serial obfuscation mechanisms of course: But given this enclosure spoils that it can’t. However if the enclosure, and it’s subsequent observation by the usb and block subsystem, is itself consistent with bay numbering then you will at least have that. I.e if a drive is not moved from one bay to the next it will always have the given say “000000000000-0:1” unique element (think those 2 same model drives where there is nothing more to tell them apart). So although less robust it is a potential, if slightly degraded’ way, of tracking a device.
Sort of it: if each bay consistently get the same 0:1 type ending irrespective of it’s content or any of the other bays content then we have a usable ‘bay stable’ system. Otherwise we do not. Rockstor attempts to track drives from their unique id (serial) up, with what this enclosure does it can only manage drives from their bay location up. That may be enough if that is in fact what’s happening here, as long as that is understood in it’s use: mostly this should be fine however.
As this is a potentially time consuming effort on both our parts please be clear on if you would like to attempt the hack path (if the above drive bay to serial mapping end up being stable)? No worries otherwise, but from my perspective it’s the second time such an enclosure has come up on the forum and they look like nicely build pieces of equipment so if we can find a way to accommodate them (if possible), given the above bay level tracking rather than device level tracking, and users are aware of this limitation, then it would be good all around to explore this option. And potentially add it as a ‘special case’ if the interest was there. If the given slot to serial stability is there, I think I see a way to make this so.
Hope that helps and let us know you findings, if you have time of course, on that bay to serial stability (irrespective of other bays content).
N.B. Be sure to also test with the first bay empty, ie do the serials then start from ‘0:1’ and not the so far observed ‘0:0’.