Names, labels instead of the name of the block device

Zitat von ABATAPA

Hello! Why does OMV not use labels, names, or mount points of file systems in the interface? It is not very convenient to see the names of block devices, as well as the UUID.

7.0-27 (Sandworm)

It is a long story. Thre is lenghty discussion about it on this forum. In the "old" days of OMV-4 "labels" were used. SInce then "UUID" was forced in and "Labels" abandoned. I have same issue as you do, so I started ut use "TAGS" to describe, in "plain language" what that device/file system is. Not the best solution IMHO but serve the purpose, for me.

UUID eliminates issues with the system identifying drives - it's just not human friendly. I now use tags to identify the slot drives are in instead of labels.

DIRTY(Create a share named "bay_3_$UUID" to identify a physical disk). You should probably use stickers with the UUID on it. Of course, a user editable label/name is nice for those without proper backplane modules.

Zitat von olduser

DIRTY(Create a share named "bay_3_$UUID" to identify a physical disk). You should probably use stickers with the UUID on it. Of course, a user editable label/name is nice for those without proper backplane modules.

Tags work for me, and I can also use the ledmon tool to flash the LED on /dev/sdX so I can identify which bay the drive is in. My server has 24 bays so I need to have a method to stay organized. Using share names as you've suggested would break mergerfs, so that is not an option for me.

Zitat von jollyrogr

flash the LED on /dev/sdX

Sure, but the association of which physical drive is on /dev/sdX is not guaranteed, not even with a backplane module. Of course you could mean that you're simply flashing the light on which ever driver is broken/focused, which obviously works and is good enough. But if you don't have a proper backplane module, how do you do that? You can't.

Zitat von jollyrogr

Using share names

Right, but there might be something handy in having the UUID listed by the filesystem using ls although I can't think of anything off hand :-/.

Zitat von olduser

Sure, but the association of which physical drive is on /dev/sdX is not guaranteed, not even with a backplane module. Of course you could mean that you're simply flashing the light on which ever driver is broken/focused, which obviously works and is good enough. But if you don't have a proper backplane module, how do you do that? You can't.

Correct, so you need to verify sdX nomenclature first. All you need to do is identify the drive in the OMV web UI by UUID and /dev/sdX and then open a terminal and use ledctl command to flash the LED. Though it certainly does not work on all machines. It works great on my 24 bay supermicro but not on the other 8 bay no-name machine. I'm not sure if it's the HBA or the backplane that is the problem...

Zitat von jollyrogr

HBA or the backplane that is the problem...

It's almost certainly the backplane unless your HBA is stripping packets/headers, which would be crazy. I tried requesting a couple samples from AMI of the MG9094 (still "solderable") but unsurprisingly never heard back. I couldn't even find a proper datasheet for _ANY_ of the controllers no matter manufacturer or age.

AMI backplane controller matrix (PDF)

Zitat von olduser

It's almost certainly the backplane unless your HBA is stripping packets/headers, which would be crazy. I tried requesting a couple samples from AMI of the MG9094 (still "solderable") but unsurprisingly never heard back. I couldn't even find a proper datasheet for _ANY_ of the controllers no matter manufacturer or age.

AMI backplane controller matrix (PDF)

Makes sense because the case is a Norco that I'm not even sure is made anymore and the backplane is made by God knows who. It was what I had before I got the supermicro 846. I'd like to retire the Norco and get another supermicro (826 or 836) for a backup server. It's actually been trouble free for the 7 years it's been in service but I would like to move to a rackmount enclosure since I have a rack now.