feat(mount): add new match patterns for device files

[Integral-Tech]

New Patterns

Device Type	Pattern
VirtIO Block Device	{ "^/dev/vd[a-z]", "%d+$" }
Xen Virtual Block Device	{ "^/dev/xvd[a-z]", "%d+$" }
Floppy Disk	{ "^/dev/fd%d+", ".+$" }
Loop Device	{ "^/dev/loop%d+", "p%d+$" }
RAID Device	{ "^/dev/md%d+", "p%d+$" }
Network Block Device	{ "^/dev/nbd%d+", "p%d+$" }
Bcache Device	{ "^/dev/bcache%d+", "p%d+$" }
RAM Disk Block Device	{ "^/dev/ram%d+", ".+$" }
zram Block Device	{ "^/dev/zram%d+", ".+$" }
Device Mapper	{ "^/dev/mapper/", ".+$" }

References

• Arch Wiki
• Wikipedia
• The Linux Storage Stack Diagram (Linux Kernel 6.16)

[sxyazi]

Thanks for your PR!

Have you tested if this plugin works with these devices too, or just added them there? I can't seem to test it myself since I have none of these devices.

[Integral-Tech]

@sxyazi I have just pushed a new commit to adjust the match patterns for device files.
Test screenshots:

All newly added match patterns have been tested, except for those involving Xen virtual block devices (/dev/xvda) and tape devices (/dev/st0 and /dev/nst0).

The naming convention of Xen virtual block devices can be found in the manual:

d0 d0p0 xvda Xen virtual disk 0 partition 0 (whole disk)
d1p2 xvdb2 Xen virtual disk 1 partition 2
d536p37 xvdtq37 Xen virtual disk 536 partition 37

The naming convention of tape devices can be found in the Red Hat Documentation:

The following is a list of the different types of tape devices:

• /dev/st0 is a rewinding tape device.
• /dev/nst0 is a non-rewinding tape device. Use non-rewinding devices for daily backups.

[sxyazi]

Thanks for the update!

If you mount/unmount or eject these devices, do they work properly?

I noticed the new commit includes even more devices, but many of them I've never seen before, do they have real-world use cases e.g. are they storage devices or are some virtual devices?

[Integral-Tech]

@sxyazi Test screenshot of Xen virtual block device:

I have just pushed a new commit to remove the pattern for tape devices, as they cannot be emulated using QEMU.

[Integral-Tech]

Thanks for the update!

If you mount/unmount or eject these devices, do they work properly?

I noticed the new commit includes even more devices, but many of them I've never seen before, do they have real-world use cases e.g. are they storage devices or are some virtual devices?

Yes, these devices function properly when I mount or unmount them.

I have just updated the table in #167 (comment) to reflect the latest changes.

VirtIO block devices and Xen virtual block devices are mainly used for virtual machines.

Loop device is a pseudo-device that makes a file accessible as a block device.

The introduction of network block device:

On Linux, network block device (NBD) is a network protocol that can be used to forward a block device (typically a hard disk or partition) from one machine to a second machine. As an example, a local machine can access a hard disk drive that is attached to another computer.

Bcache introdution from its homepage:

What is bcache?

Bcache is a Linux kernel block layer cache. It allows one or more fast disk drives such as flash-based solid state drives (SSDs) to act as a cache for one or more slower hard disk drives.

Hard drives are cheap and big, SSDs are fast but small and expensive. Wouldn't it be nice if you could transparently get the advantages of both? With Bcache, you can have your cake and eat it too.

zram introduction from ArchWiki:

zram, formerly called compcache, is a Linux kernel module for creating a compressed block device in RAM, i.e. a RAM disk with on-the-fly disk compression. The block device created with zram can then be used for swap or as a general-purpose RAM disk. The two most common uses for zram are for the storage of temporary files (/tmp) and as a swap device. Initially, zram had only the latter function, hence the original name "compcache" ("compressed cache").

As for the device mapper:

The device mapper is a framework provided by the Linux kernel for mapping physical block devices onto higher-level virtual block devices.

Applications (like LVM2 and Enterprise Volume Management System (EVMS)) that need to create new mapped devices talk to the device mapper via the libdevmapper.so shared library, which in turn issues ioctls to the /dev/mapper/control device node.