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
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.

2 Answers 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).

  • 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 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. Jun 25 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.
    – Harry
    Jun 26 at 4: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 at 8: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.
    – Harry
    Jun 26 at 9:41

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.

  • 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. Jun 25 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 at 21:59
  • /method/s//starting point/.
    – MC68020
    Jun 25 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.