¿Por qué los archivos de dispositivos especiales tienen inodos?

11

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?

— direprobs
fuente

2

El inodo y los datos son el archivo. Sin un inodo, no tienes archivo. (Sin embargo, los archivos del dispositivo no tienen ningún dato)

— user253751

16

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.

— Austin Hemmelgarn
fuente

3

Con cautela levanta la mano. He estado en un proyecto que tenía un servidor sin inodos. Finalmente, fue la crisis que nuestro equipo necesitó para convencer a la gerencia de que invirtiera en reemplazar ese sistema de fondo, que había sido diseñado (¡mal, como se puede imaginar!) Antes de que ninguno de nosotros llegara allí.

— KRyan

@KRyan Puede suceder, pero en estos días es raro a menos que el administrador reduzca explícitamente el número en la creación del sistema de archivos. Muchos sistemas de archivos modernos (al menos NTFS, BTRFS y ZFS, creo que XFS también podría) en realidad asignan inodos dinámicamente, por lo que en muchos sistemas más nuevos, en realidad es imposible quedarse sin ellos.

— Austin Hemmelgarn

@KRyan Yo también he tenido ese problema. Y en realidad era un sistema bien diseñado, aunque un poco anticuado y llevado a extremos (cada transacción requería un registro independiente, que se guardaba en el disco, eventualmente se llenaba con pequeños pequeños

— inodes

1

Od y Docker son famosos por causar exactamente este problema de inodo.

— coteyr

@AustinHemmelgarn La familia ext es bastante infame por tener un número estático de inodes (y luego agotarse). También es, por cierto, el sistema de archivos Linux más utilizado, probablemente por un margen enorme (escenarios que almacenan grandes cantidades de datos en XFS aparte, con ZFS y BTRFS siendo relativamente nuevos), y el valor predeterminado para la mayoría de las distribuciones. Por supuesto, en un sistema moderno, los inodos máximos predeterminados son muchos órdenes de magnitud mayores que la cantidad de archivos de dispositivo que tendrá.

— Bob

15

Los archivos del dispositivo también tienen permisos, y estos se almacenan en un inodo.

— Hauke Laging
fuente

Excelente punto que olvidé mencionar.

— Austin Hemmelgarn

55

No solo los permisos, sino también el tipo de archivo y otros metadatos. Clásicamente, el directorio en sí solo contiene el nombre y el número de inodo; no hay nada que indique que el archivo es un dispositivo hasta que lea el inodo.

— Gilles 'SO- deja de ser malvado'

12

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.

— Barmar
fuente

0

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.

— Dmitry Grigoryev
fuente