Linux Sin Humo (Publicaciones sobre filesystems)

¿Qué significa en Linux que todo es archivo?

sebelk — Mon, 13 May 2024 21:14:03 GMT

En un viejo artículo, hay una presentación en la que mencioné una frase bastante habitual en el mundo Unix/Linux: «Todo es archivo». Vamos a explicar qué significa realmente esa frase.

Todo es archivo

En realidad, ese dicho no es del todo correcto. Sin embargo, proviene de lo que hoy tal vez podríamos llamar la filosofía Unix. Probablemente, nadie dijo esa frase de manera literal en los primeros años de esa familia de sistemas operativos. Aun así, ideas de ese estilo estaban en la mente desde los comienzos y en los trabajos de por ejemplo, Bill Joy (pionero de TCP/IP). Linus Torvalds, no estuvo ausente en esta discusión. Y mucho más cerca en el tiempo, Lennart Poettering, retoma esa idea una vez más para defender el trabajo realizado en systemd. Por si no se dieron cuenta dice Poettering la interfaz de cgroups están expuesta en un pseudo-sistema de archivos...

Sin embargo, es más apropiado decir que todo es un descriptor de archivo o que todo puede tener un descriptor de archivo. En Linux un descriptor de archivo es un identificador único de proceso para un archivo u otro recurso de entrada o salida. Por ejemplo, no existe necesariamente un archivo para una interfaz de red. Sin embargo, existen sockets relacionados con ellas.

En el siguiente ejemplo podemos ver los descriptores de archivos para la dirección ip 127.0.0.1 de la interfaz lo.

sudo lsof -n -i@127.0.0.1
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
chronyd   1337 chrony    5u  IPv4   8171      0t0  UDP 127.0.0.1:323 
cupsd     1538   root    7u  IPv4  14727      0t0  TCP 127.0.0.1:ipp (LISTEN)
qemu-syst 1774   qemu   32u  IPv4  19480      0t0  TCP 127.0.0.1:rfb (LISTEN)
syncthing 2620 sergio   19u  IPv4  22825      0t0  TCP 127.0.0.1:8384 (LISTEN)

En este caso, vemos los descriptores de archivos de lectura y escritura 5u, 7u, 32u y 19u.

Para ver la relación entre descriptores y sockets podemos hacer un ping a una determinada dirección ip:

ping -c 10000 9.9.9.9 &> /dev/null

Si buscamos los descriptores de archivos con lsfd, mostrará el siguiente resultado:

lsfd -p 914323 -Q '(FD >= 0)' 
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping    914323 sergio     0 rw-D--    CHR  pts:6    36        9 /dev/pts/6 
ping    914323 sergio     1 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     2 -w----    CHR  mem:3    34        4 /dev/null
ping    914323 sergio     3 rw---m   PING sockfs     9 30437500 state=close id=35 laddr=0.0.0.0
ping    914323 sergio     4 rw---- PINGv6 sockfs     9 30437501 socket:[30437501]

Analicemos cada descriptor de archivo:

0: Es la "standard input" que apunta a una pseudoterminal (dispositivo de caracteres), al tratarlo como un archivo tiene permisos: de lectura y escritura. Usa un sistema de archivos y como tal también maneja inodos.
1: Es la "standard output" que apunta a /dev/null. Solamente tiene permisos de escritura, el sistema de archivos proviene de la memoria principal y tiene permisos solamente de escritura.
2: Es el "standard error" que apunta también a /dev/null.
3: Apunta a un socket de tipo IPv4, y tiene permisos de lectura y además está siendo utilizado por un evento de multiplexación.
4: Finalmente tenemos el descriptor de 5 que apunta a un tipo de socket que usa IPv6.

Dentro del directorio /proc podemos ver que los descriptores 1 (salida estándar) y 2 (error estándar) se redirigen al archivo /dev/null, mientras tanto, 3 y 4 apuntan a sockets:

ls -l /proc/914323/fd
total 0
lrwx------ 1 sergio sergio 64 may 19 17:33 0 -> '/dev/pts/6 (deleted)'
l-wx------ 1 sergio sergio 64 may 19 17:33 1 -> /dev/null
l-wx------ 1 sergio sergio 64 may 19 17:33 2 -> /dev/null
lrwx------ 1 sergio sergio 64 may 19 17:33 3 -> 'socket:[30437500]'
lrwx------ 1 sergio sergio 64 may 19 17:33 4 -> 'socket:[30437501]'

Podemos hacer otra prueba, en este caso usaremos solamente ping sobre ipv6 y en lugar de redireccionar a /dev/null, lo haremos redirigiendo stdin y stderr a archivos regulares distintos:

ping6 -c 10000 ::1 > out.txt 2> errors.txt &

Aquí solamente usará un socket (ya que no usa ipv4):

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w----    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

¿Qué sucede si se borra /tmp/errors.txt?

lsfd -p 926928 -Q '(FD >= 0)'
COMMAND    PID   USER ASSOC  XMODE   TYPE SOURCE MNTID    INODE NAME
ping6   926928 sergio     0 rw----    CHR  pts:7    36       10 /dev/pts/7
ping6   926928 sergio     1 -w----    REG   0:34    52 38207299 /tmp/out.txt
ping6   926928 sergio     2 -w-D--    REG   0:34    52 38207300 /tmp/errors.txt
ping6   926928 sergio     3 rw---- PINGv6 sockfs     9 31193485 state=close id=44 laddr=::

Bueno, veremos que el archivo aparece con el flag D indicando que borró del respectivo sistema de archivos.

Por lo tanto, si bien literalmente no todo es archivo, podemos afirmar que en general podríamos mediante los descriptores de archivos establecer un puente entre un proceso y los recursos a los que está accediendo. En definitiva, un descriptor de archivos, permite al proceso comunicarse con el recurso subyacente de manera eficiente y uniforme, independientemente de si el recurso es un archivo en el sistema de archivos, un dispositivo de hardware o un socket de red.

Enlaces útiles

¿Es btrfs el sistema de archivos que estábamos esperando?

sebelk — Sun, 13 Dec 2020 20:03:26 GMT

Digásmolo: btrfs es un sistema de archivos moderno para Linux.

Alguien leyendo esto seguramente va a pensar:

¿Qué está diciendo? ¿Cuál es la novedad? ¿Acaso no se puede rastrear los orígenes de btrfs por lo menos hasta el año 2007? ¿No es cierto que SUSE lo usa desde 2012?

Photo by Nathan Dumlao on Unsplash

Sí, todo es cierto, sin embargo, veamos la siguiente tabla:

Año	Filesystem
1993	XFS
1993	NTFS
1998	HFS+
1998	FAT32
2005	ZFS
2006	exFAT
2008	ext4
2009	btrfs
2016	APFS

La fecha de btrfs la situamos en 2009, ya que fue el año en que fue incorporado en Linux. En comparación a los demás sistemas de archivos de Linux es el más moderno (sí, ya se que existe stratis). Otro objetará diciendo que cronológicamente no hay mucho diferencia entre ext4 y btrfs. Sin embargo, leamos lo que dijo Theodore Ts'o:

Aunque ext4 tiene características mejoradas, no es un avance significativo, usa tecnología vieja y es una solución a corto plazo.

Y respecto a btrfs tuvo estos comentarios auspiciosos:

ofrece mejoras en escalabildad, confiabilidad, y facilidad de administración

Ah, ¿Ya dije que Ts'o es uno de los principales desarrolladores del sistema de archivos ext4?

Comparado con los demás sistemas operativos la ventaja es mucho más clara (HFS+ y NTFS). El sistema de archivos APFS es cierto es relativamente nuevo y apareció junto con macOS High Sierra. Es decir: Apple se tomó casi 20 años en crear un nuevo sistema de archivos. También hay que decir que en cuanto a funcionalidades, APFS y btrfs están prácticamente igualados.

Btrfs ofrece una buena cantidad de características, las que me parece importante resaltar son:

Subvolúmenes: Es un directorio que funciona como un volumen. Como tal, tiene su propia espacio de inodos. Por ejemplo:

Cada uno de estos archivos muestran un dispositivo diferente:

No obstante, cabe aclarar que no son dispositivos de bloque distintos como podría ser un volumen lógico en LVM.

Cada subvolumen puede ser montado con diferentes opciones e incluso en un +arbol completamente independiente para el usuario o aplicaciones que accede al mismo.

CoW: Los usuarios de Linux estamos acostumbrados a usar enlaces duros y enlaces simbóicos. Cada uno tiene sus ventajas y limitaciones. Esta funcionalidad permite copiar un archivo usando otro inodo pero sin consumir más espacio, ya que referencia en realidad al archivo original. Si se hace una modificación en la copia, los metadatos comienzan a apuntar a los nuevos datos. Gracias esta característica podemos hacer subvolumenes que contengan una instantánea de otro subvolumen existente. Todo esto de una manera mucho más consistente que con LVM.
Compresión: Otra de las ventajas es la compresión transparente, la cual puede ser por el sistema de archivo entero, por directorio o por archivo (pero por ahora, no por subvolumen).

Hay muchas razones para creer que btrfs puede y/o debería reemplazar a ext4 o xfs. De paso recordemos que xfs no soporta achicar un sistema de archivos y si pensamos zfs como una buena opción, hay problemas tanto de licenciamiento como en rendimiento (ver el artículo de Valerie Aurora, creadora de relatime y autoridad en la materia). Las ediciones de Fedora 33 para estaciones de trabajo y SUSE/openSUSE usan btrfs como sistema de archivos predeterminado. De esta manera podríamos prescindir de LVM e incluso de mdadm para RAID (btrfs tiene su propio soporte para RAID - aunque hay que tener en cuenta que RAID[56] no se considera estable aun). El proyecto btrfs debería tener cuidado de sí mismo, tiene tantas funcionalidades que como dice el dicho "lo perfecto es enemigo de lo bueno" (Ah, por cierto el autor de la frase es de Voltaire, alguien que precisamente no se conformaba con poco). Es decir, el único riesgo que veo en el futuro es convertirse en algo tan complejo que sea difícil de administrar o mantener. Veremos en unos años si logra posicionarse como el sistema de archivos de código abierto más utilizado.

Fuentes y más recursos

Creación de Archivos Temporales

sebelk — Fri, 13 Sep 2019 11:43:01 GMT

Algo bastante frecuente es crear archivos temporales a mano para probar cierto código. Estaba bastante acostumbrado a crear archivos del tipo /tmp/q[0-9]. Así, terminaba con muchos archivos con ese patrón. Hay varios problemas con eso, uno de ellos es que si ya tenemos abierto un archivo /tmp/q1 por ejemplo, podemos fácilmente olvidar eso y abrirlo en otra shell con vim. Y ya sabemos como nuestro querido editor se molesta (y con razón en esos casos). Un truco que se me había ocurrido era crear un alias de este tipo: alias viq='alias viq='vi /tmp/q$(date +'%s')'

El problema con ese approach es que no era reutilizable. Es decir al ejecutarlo de vuelta abría un archivo con otro nombre. Existe una opción que es tal vez mejor y es usar el comando mktemp.

Ejemplo:

mktemp 
/tmp/tmp.7WUOKYMTEQ

Es decir, crea el archivo /tmp/tmp.7WUOKYMTEQ

Si el archivo deseamos crearlo en otro lugar, sencilamente hacemos algo así:

mktemp -d /home/sergio/temp

También podemos editar el archivo directamente:

mktemp|xargs vim -

La poderosa shell de GRUB 2

sebelk — Fri, 02 Oct 2015 13:34:58 GMT

En el artículo anterior hemos visto que la línea de comandos de GRUB nos permitía reparar el cargador de arranque sin necesidad de recurrir a un cargador de arranque.

GRUB2 como es de suponer también permite hacerlo:

grub> set root=(hd0,1)
grub> linux /vmlinuz-3.16.0 root=/dev/mapper/centos-root ro
grub> initrd /initramfs-3.16.0.img
grub> boot

Como vemos cambian algunos comandos, sintaxis y la nomenclatura de particiones pero la idea es la misma.

Desde ya contamos con la tecla TAB para autocompletar rutas de archivo y el comando cat:

Arrancar directo desde un archivo ISO

Bajamos una distro y no queremos ni tenemos tiempo para grabarla en un CD/DVD. Perfecto, GRUB2 en la mayoría de los casos puede arrancar también una imagen ISO:

grub> set isofile=/TinyCore.iso 
grub> loopback loop (hd0,1)/$isofile vmlinuz 
grub> linux (loop)/boot/vmlinuz cde loglevel=3 
grub> initrd (loop)/boot/core.gz

Tener acceso a un archivo de un LVM

Sí, estimados, GRUB2 puede también leer un volumen lógico, ¿Cómo? Así:

Algo más

¿Más? Sí, mas todavía, por ejemplo listar dispositivos en el bus PCI:

Como se puede apreciar GRUB es bastante más que un boot loader y su shell lo suficientemente potente como para prescindir de un LiveCD (al menos en soporte físico) en más de una ocasión.

Información complementaria

How to Rescue a Non-booting GRUB 2 on Linux

Una presentación sobre sistemas de archivos

sebelk — Sun, 26 Oct 2008 18:07:03 GMT

Ángel Vilte de la Facultad de la Universidad de la Plata me invitó a dar una charla para un evento de software libre. Las diapositivas de la misma se pueden descargar haciendo clic en filesystems .

Fragmentacion en ext3

sebelk — Fri, 21 Mar 2008 15:35:25 GMT

En repetidas oportunidades se ha dicho que Linux, o más precisamente que ext2 y ext3 no necesitan un defragmentador. La fragmentación existe, pero se supone que no afecta el rendimiento de esos sistemas de archivos. Sin embargo, al mejor estilo Unix, existe una aplicación no muy conocida llamada filedefrag que sirve para ver el grado de fragmentación de un determinado archivo.

Se puede leer un interesante y artículo y discusión al respecto en OneAndOneIs2, además de esta mención en Wikipedia de ext3.

Acceder a imágenes ISO

sebelk — Tue, 29 Jan 2008 19:08:24 GMT

De acuerdo a Wikipedia, una Imagen ISO es Imagen ISO

es un archivo donde se almacena una copia o imagen exacta de un sistema de ficheros, normalmente un disco compacto (como un CD o un DVD)

Algo interesante es que uno puede acceder al interior del archivo y explorar las carpetas y los archivos de manera bastante transparente.

Supongamos que tenemos el archivo mandriva-linux-2008-one-KDE-cdrom-i586.iso

Para ver el contenido es cuestión de montar el archivo como si fuera un sistema de archivos. Esto se consigue gracias al módulo loop del kernel.

Entonces sencillamente se puede hacer:

mkdir /loop1  
mount -o loop mandriva-linux-2008-one-KDE-cdrom-i586.iso /loop1

Entonces, se puede ver el contenido de la imagen ISO:

ls
boot isolinux LISEZMOI.pdf loopbacks README.pdf

Dentro del directorio loopbacks de la imagen está el directorio loopbacks. Podemos ver su contenido:

ls /loop1/loopbacks  
distrib.sqfs

¿De qué tipo de archivo se trata?

/loop1/loopbacks/distrib.sqfs: Squashfs filesystem, little 
endian, version 3.0, 721071324 bytes, 98645 inodes, blocksize: 65536 
bytes, created: Mon Oct 8 19:01:20 2007

Se trata justamente de un sistema de archivos squashfs usado con frecuencia en Live-CDs, ya que permite compresión de archivos y tiene soporte para escritura.

Se puede montar este sistema de archivos también:

mkdir /loop2  
mount -o loop -t squashfs /loop1/loopbacks/distrib.sqfs /loop2  
ls -l /loop2  
total 0  
drwxr-xr-x 2 root root 1122 oct 8 04:53 bin  
drwxr-xr-x 3 root root 201 oct 8 12:19 boot  
drwxr-xr-x 26 root root 63160 oct 8 05:03 dev  
drwxr-xr-x 96 root root 2969 oct 8 05:04 etc  
drwxr-xr-x 3 root root 22 oct 8 05:04 home  
drwxr-xr-x 2 root root 3 jul 27 2007 initrd  
drwxr-xr-x 13 root root 2523 oct 8 05:04 lib  
drwxr-xr-x 4 root root 33 oct 8 04:50 media  
drwxr-xr-x 3 root root 21 oct 8 04:50 mnt  
drwxr-xr-x 2 root root 3 jul 27 2007 opt  
drwxr-xr-x 2 root root 3 oct 8 04:36 proc  
drwx—— 9 root root 203 oct 8 05:04 root  
drwxr-xr-x 2 root root 3764 oct 8 05:04 sbin  
drwxr-xr-x 2 root root 3 oct 8 04:36 sys  
drwxrwxrwt 5 root root 56 oct 8 12:19 tmp  
drwxr-xr-x 12 root root 167 oct 8 04:50 usr  
drwxr-xr-x 16 root root 154 oct 8 04:50 var

¿Suena familiar? Todo este arbol de directorios con sus archivos es el que se descomprime luego de arrancar el Live-CD.

Inspeccionando un poco más se ve que el directorio boot contiene un INIT Ram Disk y la imagen compilada del kernel Linux. De manera que todo estos archivos se pueden copiar a una partición, y configurando apropiadamente GRUB puede arrancarse directamente desde el disco rígido. De manera que nos ahorramos un CD…