[FEATURE] Possible to enumerate the drives as /dev/sd* or /dev/nvme*

[cmc0619]

I'd like to use these drives in an Unraid server but their software only looks for devices named under /dev/sd* or /dev/nvme*. Is there a way to change how these drives present? Maybe something "simple" as a udev rule file that could be created? Or a barring that switch that could be specificied on module load?

[Tourman36]

There's no way to do this. It's hardcoded in the firmware driver, and we don't have the source code for that.

…

On Mon, Dec 28, 2020 at 6:35 PM cmc0619 ***@***.***> wrote: I'd like to use these drives in an Unraid server but their software only looks for devices named under /dev/sd* or /dev/nvme*. Is there a way to change how these drives present? Maybe something "simple" as a udev rule file that could be created? Or a barring that switch that could be specificied on module load? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#74>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO7IG5BRP7VAZRACFA7NXZ3SXEI43ANCNFSM4VMSZKJQ> .

[snuf]

Hi @cmc0619 as @Tourman36 pointed out we're not in full control of that atm. The easiest way to do this is with have udev trigger and create a symlink or something probably. You can find an example here: https://unix.stackexchange.com/questions/119593/is-there-a-way-to-change-device-names-in-dev-directory#:~:text=1%20Answer&text=According%20to%20udev%20manual%2C%20there's,additional%20symlinks%20can%20be%20created.

[bplein]

I'd like to use these drives in an Unraid server but their software only looks for devices named under /dev/sd* or /dev/nvme*. Is there a way to change how these drives present? Maybe something "simple" as a udev rule file that could be created? Or a barring that switch that could be specificied on module load?

This is best left to the Unraid folks... they are the ones making assumptions about what a device is named. I'd go as far as saying "lsblk correctly identifies /dev/fio* as block devices, why doesn't UNRAID" and let them sort it out. That's a bug!

[snuf]

@cmc0619 I did some digging, the main issue is that unraid uses /dev/disk/by-id hardcoded from the emhttpd service (at least it seems). The /dev/disk/by-id device list gets setup by the persistent storage links in udev. Because fusion IO is not part of Linux, as in it's not part of the kernel. To make this work you could add the fio* device to the list of devices that get a by-id link created. The addition should be done in /lib/udev/rules.d/60-persistent-storage.rules, or as a file that ads the specific rule. I've attached a screenshot of what's there for NVME, for fusion IO similar rules can be added (looking at sd also helps). The fio-tools only contain a udev rule set for /dev/disk/by-path and not /dev/disk/by-id. To @bplein 's point, looking at /dev/disk/by-id is cute but it's a not so great assumption. I do understand why though, as it's easy to relate a drive's serial number when the ID is used.

In the example above the ID is set by a program, for a fio device this could be fio-status --field adapter.fio_serial_number /dev/$devnode which would result in the device showing up as fio-<serial number>.

Let me know if this helps?

[bplein]

This is what FOSS is all about 😀 Happy new year!

[arrjay]

you will need fio-utils installed, but this seems to create some disk/by-id and disk/by-path nodes:

# persistent storage links for iomemory-vsl devices.
# requires fio-status in /usr/bin.

ACTION=="remote", GOTO="persistent_fio_end"
ENV{UDEV_DISABLE_PERSISTENT_STORAGE_RULES_FLAG}=="1", GOTO="persistent_fio_end"

SUBSYSTEM!="block", GOTO="persistent_fio_end"
KERNEL!="fio*", GOTO="persistent_fio_end"

# this was copied over from 60-persistent-storage, I believe it tries to see
# if /sys/block/fio*/whole_disk merely exists
TEST=="whole_disk", GOTO="persistent_fio_end"

# partition handling also originates there.
ENV{DEVTYPE}=="partition", \
  IMPORT{parent}="ID_[!F]*", IMPORT{parent}="ID_", \
  IMPORT{parent}="ID_F[!S]*", IMPORT{parent}="ID_F", \
  IMPORT{parent}="ID_FS[!_]*", IMPORT{parent}="ID_FS"

KERNEL=="fio[a-z]", PROGRAM="/usr/bin/fio-status --field iom.format_uuid /dev/%k", SYMLINK+="disk/by-id/fio-%c"
KERNEL=="fio[a-z][0-9]*", ENV{DEVTYPE}=="partition", PROGRAM="/usr/bin/fio-status --field iom.format_uuid /dev/%P", SYMLINK+="disk/by-id/fio-%c-part%n"

# by-path
KERNEL=="fio[a-z]", PROGRAM="/usr/bin/fio-status --field iom.pci_addr /dev/%k", SYMLINK+="disk/by-path/pci-0000:%c-%k"
KERNEL=="fio[a-z][0-9]*", ENV{DEVTYPE}=="partition", PROGRAM="/usr/bin/fio-status --field iom.pci_addr /dev/%P", SYMLINK+="disk/by-path/pci-0000:%c-%P-part%n"

LABEL="persistent_fio_end"

if you would rather use the serial numbers of the fio than the formatted UUID, replace iom.format_uuid with iom.fio_serial_number

[arrjay]

#76

[snuf]

@cmc0619 the file is merged into the main branch, if you could check if it solves your problem that would be great?

[cmc0619]

You guys are amazing. Unfortunately, I'm away from my server for a few weeks. I've updated the thread on the lime technologies webpage to ask if anyone else can confirm.

[jcarron2]

Thanks everyone for the hard work on getting this going! Just a question, does the above go into the /lib/udev/rules.d ?

[snuf]

@jcarron2 typically I think you'd place it in /etc/udev/rules.d/<number>-fio.rules, or at least that's where it would live on Ubuntu.

[snuf]

closing this as there is a udev rules file now.