2

I have seen some configurations using udev rule to insure the disk name and permissions in the disk. But recently I've find out a command called mknod, where it works like an alias to the block device, by specify the major:minor of the disk, we can "create an alias", something like it:

[root@dbnode1 disks]# lsblk
NAME                MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdd                   8:48   0  160M  0 disk

mknod /disks/QUORUML b 8 48

Now I'd like to know why to use udev rules instead of mknod, since mknod is very simple to use. My main point is insure persistent naming and permission.

Potter
  • 425
  • 4
  • 12

2 Answers2

2

Why ? Reliability !

The major and minor device numbers are allocated when the driver detects a new device and, when a device is removed, these device numbers are freed and can be reused later.

The consequence of this being that the association between the device numbers and corresponding sd labels changes when the order of detection change.

This might be considered unusual on a small system with a unique disk, however just think of removable medias, hot pluggable disk arrays… cover this with parallelized detection… sdb, sdc,… the order is, strictly speaking : unpredictable.

This is the reason why it is undesirable to use the major and minor number range (or the associated sd names when referring to devices, such as in the /etc/fstab file). The wrong device could be mounted leading to big troubles.

MC68020
  • 6,281
  • 2
  • 13
  • 44
  • Your answer isn’t really about `udev` v. `mknod`, it’s about what to use to access a drive’s contents. `udev` does make it easier with the `by-id` etc. aliases it provides; but it is possible to mount by label or UUID with static device nodes too, or to use LVM on top of static nodes. – Stephen Kitt Jun 25 '22 at 21:06
  • @StephenKitt : I agree. My answer was about persistent device naming and why device's major/minor can in no way stand as a reliable method. – MC68020 Jun 25 '22 at 21:59
  • /method/s//starting point/. – MC68020 Jun 25 '22 at 22:24
2

The biggest reason is that udev rule is "automatic" -- every time a new device is connected (or discovered during boot), udev will process all the rules files so you don't need to do anything manually.

Also mknod creates a new block (or character) device file, but you already have one -- /dev/sdd so you don't need to create a new one, you only need a symlink to it (which is what udev does with the SYMLINK property).

If you don't want/need the "automation" part of udev and are ok with running a command manually every time you boot or connect the device, I suggest you still shouldn't use mknod but create a symlink instead.

If all you want is a nice (and stable) "path" for the device, I'd suggest setting label for the filesystem or partition and then you can use one of the default symlinks created by udev in /dev/disk/by-partlabel and /dev/disk/by-label.

Note that udev is also used by other system tools that work with storage so if you create the symlink with udev, these will know that it is a symlink to that device. This might not be true with manually created nodes (but for example lsblk is smart enough and if you run lsblk /disks/QUORUML it will show you /dev/sdd).

Vojtech Trefny
  • 16,922
  • 6
  • 24
  • 48
  • Reading your answer, I would understand its a simple matter of user's comfort ! It is actually **not**. It is a matter of **reliability**. – MC68020 Jun 25 '22 at 20:47
  • The question is about udev vs mknod. Nothing blocks you from using major/minor in udev rules and have the same unreliable result. Yes, udev allows you more flexibility than mknod, but I wouldn't say that is the main reason for using udev. – Vojtech Trefny Jun 25 '22 at 20:50
  • Thanks for the answers. About "and are ok with running a command manually every time you boot or connect the device" did you mean run mknod? I've tested here and don't need to run mknod every time the system is rebooted. – Potter Jun 26 '22 at 04:42
  • 1
    @Harry Yeah, but where do you get the major/minor combination from? If you just hardcode it, the device file that you create using mknod might end up referring to different actual block devices after every reboot. So the only way to make it reliable is to rm and mknod the files after every reboot based on what the current minors are (the minor is assigned dynamically). If you do that, you have just reinvented udev! – TooTea Jun 26 '22 at 08:45
  • I get from lsblk command. But I guess I got it, maybe the major:minor can change in some moment. In my tests has not changed, but it can happen. – Potter Jun 26 '22 at 09:41
  • @Harry: For many older device types including the 'sdX' devices, their names directly correspond to the minor numbers. (In other words there's a predefined mapping: for example, 'sdc' is assigned 8:32 to 8:47, and 'sdd' is assigned 8:48 to 8:63, with space for 15 partitions.) So if the device becomes sdc instead of sdd after a reboot (which happens often!), that's literally *because* it also has a different minor. It's often seen when different disk types are connected (e.g. SATA + USB) that share the same sd# space; sometimes sda is USB, sometimes SATA, whichever happens to probe faster. – u1686_grawity Jun 26 '22 at 11:43