Los archivos del dispositivo no son archivos per se. Son una interfaz de E / S para usar los dispositivos en sistemas operativos tipo Unix. No usan espacio en el disco, sin embargo, todavía usan un inodo según lo informado por el statcomando:
$ stat /dev/sda
File: /dev/sda
Size: 0 Blocks: 0 IO Block: 4096 block special file
Device: 6h/6d Inode: 14628 Links: 1 Device type: 8,0
¿Los archivos del dispositivo usan inodos físicos en el sistema de archivos y por qué los necesitan?
filesystems
devices
inode
stat
direprobs
fuente
fuente
Respuestas:
La respuesta corta es que solo lo hace si tiene un respaldo de sistema de archivos físico
/dev(y si está utilizando una distribución moderna de Linux, probablemente no).La respuesta larga sigue:
Todo esto se remonta a la filosofía original de UNIX de que todo es un archivo. Esta filosofía es parte de lo que hizo que UNIX fuera tan versátil, porque podía interactuar directamente con los dispositivos desde el espacio de usuario sin necesidad de tener un código especial en su aplicación para comunicarse directamente con el hardware físico.
Originalmente,
/devera solo otro directorio con un nombre conocido donde colocaba los archivos de su dispositivo. Algunos sistemas UNIX aún adoptan este enfoque (creo que OpenBSD todavía lo hace), y generalmente puede saber si un sistema es así porque tendrá muchos archivos de dispositivo para dispositivos que el sistema no tiene realmente (por ejemplo, archivos para cada posible partición en cada disco posible). Esto ahorra espacio en memoria y tiempo en el arranque a costa de usar un poco más de espacio en disco, lo cual fue una buena compensación para los sistemas iniciales porque generalmente tenían mucha memoria y no eran muy rápidos. Esto generalmente se conoce como tener una estática/dev.En los sistemas Linux modernos (y creo que también FreeBSD y posiblemente versiones recientes de Solaris),
/deves un sistema de archivos temporal en memoria poblado por el núcleo (o udev si usa Systemd, porque no confían en que el núcleo haga casi nada) . Esto ahorra algo de espacio en disco al precio de algo de memoria (generalmente menos de unos pocos MB) y una sobrecarga de procesamiento muy pequeña. También tiene una serie de otras ventajas, siendo una de las más grandes que es más fácil detectar hardware conectado en caliente. Esto generalmente se conoce como tener una dinámica/dev.Sin embargo, en ambos casos, se accede a los nodos del dispositivo a través de la capa VFS normal, lo que por definición significa que tienen que tener un inodo (incluso si es virtual y simplemente existe para que cosas como
stat()funcionen como se supone.) Desde una perspectiva práctica, esto tiene un impacto cero en los sistemas que usan una dinámica/devporque solo almacenan los inodos en la memoria o los generan según sea necesario, y un impacto cercano a cero donde/deves estático porque los inodos ocupan casi cero espacio en el disco y la mayoría de los sistemas de archivos no tienen límite superior ellos o aprovisionarlos mucho más de lo que cualquiera pueda necesitar.fuente
Los archivos del dispositivo también tienen permisos, y estos se almacenan en un inodo.
fuente
Los directorios son simplemente una asignación de nombres de archivo a inodes, por lo que todo lo que se refiere al nombre (un archivo, un enlace simbólico, un dispositivo, un FIFO, un socket) debe estar en el inodo, no hay otro lugar para colocarlo.
La información sobre el dispositivo se almacena en el inodo. Los números de dispositivo mayor y menor están allí, al igual que los permisos, las marcas de tiempo, etc. El campo de tipo que dice que es un dispositivo de bloque o de caracteres en lugar de un archivo normal se almacena allí.
El inodo para dispositivos simplemente no utiliza los campos que contienen el mapa de bloques del archivo.
fuente
Sin un inodo, solo tendría el nombre del archivo para contener toda la información sobre el dispositivo en cuestión. Esto significa que los nombres de dispositivos "agradables"
/dev/sdaestarían fuera de discusión: necesitaría un nombre que pudiera estar vinculado a un controlador en particular, como/dev/ohci/sda.Aún más importante, todas las herramientas que dependen de inodes (como
stat,lsetc.) tendrían que modificarse para tratar las rutas bajo/devde una manera especial. Esa sería una cantidad prohibitivamente grande de trabajo sin beneficio aparente en comparación con el estado actual de las cosas.fuente