mount -t devtmpfs
Во многих современных системах /dev
обычно является типом файловой системы, который можно монтировать куда угодно. Например. в Ubuntu 16.04:
mkdir d
sudo mount -t devtmpfs none d
head -c 10 d/random
sudo umount d
и теперь d/
содержит то же самое, что и /dev
.
Это разрешено CONFIG_DEVTMPFS=y
и позволяет ядру самому создавать и уничтожать файлы устройств по мере необходимости.
CONFIG_DEVTMPFS_MOUNT=y
Этот параметр заставляет ядро автоматически -монтировать devtmpfs на /dev
во время загрузки. Например, он включен в Ubuntu 21.04.
drivers/base/Kconfig
документы:
config DEVTMPFS_MOUNT
bool "Automount devtmpfs at /dev, after the kernel mounted the rootfs"
depends on DEVTMPFS
help
This will instruct the kernel to automatically mount the
devtmpfs filesystem at /dev, directly after the kernel has
mounted the root filesystem. The behavior can be overridden
with the commandline parameter: devtmpfs.mount=0|1.
This option does not affect initramfs based booting, here
the devtmpfs filesystem always needs to be mounted manually
after the rootfs is mounted.
With this option enabled, it allows to bring up a system in
rescue mode with init=/bin/sh, even when the /dev directory
on the rootfs is completely empty.
file_operations
Наконец, вы должны создать свой собственный модуль ядра символьного устройства, чтобы точно видеть, что происходит.
Вот минимальный исполняемый пример.:Как работают символьные устройства или специальные файлы символов?
Наиболее важным шагом является настройка структуры file_operations
, например.:
static const struct file_operations fops = {
.owner = THIS_MODULE,
.read = read,
.open = open,
};
static int myinit(void)
{
major = register_chrdev(0, NAME, &fops);
return 0;
}
, который содержит указатели на функции, которые вызываются для каждого системного вызова, -связанного с файлом.
Затем становится очевидным, что вы переопределяете системные вызовы, связанные с файлом -, чтобы делать все, что вы хотите, и таким образом ядро реализует такие устройства, как /dev/zero
.
Создать /dev
записи автоматически безmknod
Последняя загадка заключается в том, как ядро автоматически создает /dev
записи.
Механизм можно наблюдать, создав модуль ядра, который делает это самостоятельно, как показано в :https://stackoverflow.com/questions/5970595/how-to-create-a-device-node-from-the-init-module-code-of-a-linux-kernel-module/45531867#45531867, и сводится к вызову device_create
.
ddrescue успешно скопировал с диска с поврежденными секторами на тот, который был отключен из массива еще в ноябре, правда, только после того, как я заменил блок питания. В /var/log/kern.log я увидел сотни неудачных команд WRITE FDMA QUEUE, поэтому вытащил блок питания с более новой машины, и после пересадки ddrescue заработал нормально. Для дисков 4 ТБ ушло около 10 часов. Он сообщил о 15 ошибках общим объемом 80 КБ. После завершения sdd выглядел точно так же, как и sdc, как и следовало ожидать, поэтому я собрал массив с sdb sdd и sde, затем добавил sdd и позволил ему восстановиться, что завершилось без ошибок. Фактически, SMART больше не сообщает о поврежденных секторах на sdd. Я предполагаю, что это связано с тем, что запись в эти сектора привела к перераспределению секторов на диске. Так что все хорошо, просто нужно заказать новый блок питания.