¿Casos de uso para enlaces duros? [cerrado]

40

¿En qué situaciones se desearía usar un enlace duro en lugar de un enlace suave? Personalmente, nunca me he encontrado con una situación en la que me gustaría usar un enlace rígido sobre un enlace blando, y el único caso de uso que he encontrado al buscar en la web es deduplicar archivos idénticos .

filesystems hard-link

— Matthew Cline
fuente

44

Hay buenas respuestas a continuación, pero considere el contexto histórico (discutible). Cuando Unix era nuevo, las unidades de disco eran lentas y tenían capacidad y almacenamiento en búfer limitados. Un enlace duro era simplemente otra entrada directa en el sistema de archivos al mismo archivo. Si estaba accediendo a ls , o como le gustaba llamarlo, la lista era irrelevante. Si hubiera hecho de la lista un enlace suave, su uso implicaría encontrarlo en el directorio, leer el archivo especial llamado lista , ver que desea el archivo ls , encontrar ls en el directorio y leer el archivo ls real del disco. ¡Una gran diferencia en el rendimiento!

— RichF

16

Bueno, el primer enlace duro a un archivo es bastante útil.

— Deja de dañar a Mónica el

@OrangeDog: Sí, pero solo necesita un campo de recuento de enlaces en el inodo si desea admitir múltiples enlaces. (Es posible que necesite un indicador para la versión en memoria de los inodos para manejar el caso no vinculado pero aún abierto. Fsck después de un bloqueo sin registro en el diario aún tendría que buscar inodos sin enlaces de ninguna manera.)

— Peter Cordes

1

La semántica del directorio POSIX debería diseñarse de manera diferente: ..siempre es el mismo inodo que .en el directorio padre. Cosas como findpueden verificar ese conteo de enlaces = 2 para detectar directorios hoja y evitar statlas entradas de readdir para buscar subdirectorios. Pero esa es solo una característica menor habilitada por el soporte para enlaces duros de archivos que no son de directorio (regular, enlace simbólico, dispositivo, socket y canalización con nombre). (Sí, los enlaces simbólicos tienen su propio inodo y se pueden vincular).

— Peter Cordes

1

Una razón para usar enlaces duros que no he visto en mi revisión de SO, de naturaleza "global". Imagine un sistema de archivos donde los archivos son generalmente pequeños (en su mayoría memos cortos, por ejemplo), pero para mantener las cosas organizadas puede necesitar punteros al mismo archivo en diferentes lugares. Con enlaces simbólicos, cada puntero usa un inodo. Es posible que dichos sistemas de archivos ya tengan un problema al quedarse sin inodos. El uso de enlaces duros como punteros ayuda con este problema. los inodos son limitados en número; los nombres para ellos no son (al menos, no de la misma manera).

— Mathguy

27

Además del uso de copia de seguridad mencionado en otro comentario, que creo que también incluye las instantáneas en un volumen BTRFS, un caso de uso para enlaces duros sobre enlaces blandos es una colección de archivos ordenados por etiquetas. (No es necesariamente el mejor método para crear una colección, un método basado en una base de datos es potencialmente mejor, pero para una colección simple que sea razonablemente estable, no está tan mal).

Una colección de medios donde todos los archivos se almacenan en un solo directorio plano y se clasifican en otros directorios en función de varios criterios, es decir: año, tema, artista, género, etc. Esto podría ser una colección personal de películas o un estudio comercial colectivo. trabajos. Esencialmente terminado, el archivo se guarda, no es probable que sea modificado y ordenado, posiblemente en múltiples ubicaciones por enlaces.

Tenga en cuenta que el concepto de "original" y "copia" no son aplicables a los enlaces duros: cada enlace al archivo es original, no hay "copia" en el sentido normal. Para la descripción del caso de uso, sin embargo, los términos imitan la lógica del comportamiento.

El "original" se guarda en el directorio "catálogo", y las "copias" ordenadas están vinculadas a esos archivos. Los atributos de archivo en los directorios de clasificación se pueden establecer en r / o, evitando cualquier cambio accidental en los nombres de archivo y la estructura ordenada, mientras que los atributos en el directorio de catálogo pueden ser r / w permitiendo que se modifique según sea necesario. (El caso sería archivos de música en los que algunos reproductores intentan cambiar el nombre y reorganizar los archivos en función de las etiquetas incrustadas en el archivo multimedia, de la entrada del usuario o de la recuperación de Internet). Además, dado que los atributos de los directorios de "copia" pueden ser diferentes a el directorio "original", la estructura ordenada podría estar disponible para el grupo, o el mundo, con acceso restringido, mientras que el "catálogo" principal solo es accesible para el usuario principal, Con pleno acceso. Sin embargo, los archivos mismos siempre tendrán los mismos atributos en todos los enlaces a ese inodo. (Se podría explorar ACL para mejorar eso, pero no mi área de conocimiento).

Si se cambia el nombre o se mueve el original (por ejemplo, el único directorio "catálogo" se vuelve demasiado grande para administrar) los enlaces duros permanecen válidos, los enlaces blandos se rompen. Si las "copias" se mueven y los enlaces blandos son relativos, los enlaces blandos volverán a romperse y los enlaces duros no.

Nota: parece haber inconsistencia en cómo diferentes herramientas informan el uso del disco cuando están involucrados los enlaces blandos. Con enlaces duros, sin embargo, parece consistente. Entonces, con 100 archivos en un catálogo ordenados en una colección de "etiquetas", fácilmente podría haber 500 "copias" vinculadas. (Para una colección de fotografías, diga fecha, fotógrafo y un promedio de 3 etiquetas de "sujeto"). Dolphin, por ejemplo, informaría que 100 archivos para enlaces duros y 600 archivos si se usan enlaces blandos. Curiosamente, informa el mismo uso de espacio en disco de cualquier manera, por lo que parece una gran colección de archivos pequeños para enlaces blandos, y una pequeña colección de archivos grandes para enlaces duros.

Una advertencia para este tipo de caso de uso es que en los sistemas de archivos que usan COW, modificar el "original" podría romper los enlaces duros, pero no romper los enlaces blandos. Pero, si la intención es tener la copia maestra, después de editar, guardar y ordenar, COW no entra en el escenario.

— Tejedor de hechizos gitano
fuente

3

FYI: las instantáneas de btrfs no son enlaces duros. Tienen un comportamiento diferente (por ejemplo, modificar una copia no modifica la otra). Y statmostrará solo un enlace.

— derobert

@derobert No estoy seguro de cómo funcionan las instantáneas, poca investigación muestra cosas interesantes. Para archivos / directorios sin cambios, statmuestre el mismo número de inodo, pero diferente ID de dispositivo. Debe tener algo que ver con la forma en que los subvolúmenes se superponen en el volumen principal, rara vez montado. Sospecho que si se montara el volumen principal stat, mostraría un recuento de enlaces igual al número de instantáneas que contenía esa versión del archivo. VACA probablemente se encarga de que el modificador no afecte a los demás. Mera especulación basada en una leve curiosidad, pero no lo suficientemente curiosa como para cavar más profundo.

— Gypsy Spellweaver

Cada enlace simbólico tiene su propio inodo, por lo que utiliza una entrada de inodo en el sistema de archivos. Los sistemas de archivos tradicionales de Unix requieren que elija cuánto espacio reservar para los inodos en el momento de la creación de FS, en lugar de asignarlo según sea necesario como lo hace XFS. Por lo tanto, es realmente significativo que la versión de enlace simbólico use muchos más inodos (incluso además de las implicaciones de huella de caché VFS).

— Peter Cordes

23

Los enlaces duros son útiles para casos en los que no desea vincular la existencia de ambos archivos. Considera esto:

touch a
ln -s a b
rm a

Ahora bes inútil. (Y estos pasos pueden suceder bastante separados, ser realizados por diferentes personas, etc.)

Mientras que con un enlace duro,

touch a
ln a b
rm a

b sigue presente y correcto.

— Stephen Kitt
fuente

8

@MatthewCline Desea este comportamiento al administrar copias de seguridad incrementales eficientes. Especialmente cuando se eliminan las copias de seguridad antiguas, en un sistema de copia de seguridad basado en enlaces blandos, tendría que verificar y volver a vincular todos los archivos / enlaces de copia de seguridad más nuevos a una base válida nuevamente, mientras que los enlaces duros hacen ese trabajo "gratis" a nivel de inodo. Timeshift / backintime, por ejemplo, usa enlaces duros de forma extensiva.

— orzechow

3

@orzechow No creo que desee un comportamiento de enlace duro cerca de su sistema de respaldo. github.com/bit-team/backintime/wiki/… backintime asume tontamente que todos los cambios en los archivos se realizarán mediante un ciclo de eliminación-creación en lugar de actualizarse.

— DepressedDaniel

10

Los enlaces duros @DepressedDaniel están bien dentro de un sistema de copia de seguridad, simplemente no desea que las copias de seguridad estén vinculadas a los archivos en vivo. Pero, en cualquier caso, una copia de seguridad nunca debe ser accesible directamente desde un sistema en vivo ...

— Stephen Kitt

1

Esta no es una respuesta, específicamente, no es un caso de uso. Es solo una demostración del comportamiento de los enlaces duros.

— user394

1

@ ThomasPadron-McCarthy es un malentendido. BiT usa enlaces duros solo para vincular archivos idénticos dentro de diferentes instantáneas. ¡NO están vinculados al archivo original! (Soy el Dev BiT)

— Germar

11

Un solo programa puede cambiar su comportamiento dependiendo de qué nombre se inicie como:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Lo cual en la fuente se decide a través de algo como

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

aunque los detalles exactos variarán según el sistema operativo y el idioma involucrado.

Esto permite que (en su mayoría) el código idéntico no tenga que compilarse en dos binarios (en su mayoría) idénticos. Tenga en cuenta que las fechas de Unix son días en que el espacio en disco era muy costoso, aunque según Stevens en el capítulo 4 de APUE, los enlaces simbólicos se implementaron en BSD4.2 (1983) para reemplazar varias limitaciones de los enlaces duros. Un programa de prueba para verificar si se utiliza el nombre del enlace simbólico, ya que el nombre del programa podría verse así:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

Y probado a través de:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$

— thrig
fuente

44

Pero, ¿no se maneja generalmente con enlaces suaves?

— Matthew Cline

1

@MatthewCline podría ser hoy, pero los enlaces simbólicos no existían antes de 4.2BSD (1983) según Stevens en APUE.

— 2017

44

@thrig, la pregunta específicamente solicita casos de uso que no pueden lograrse mediante enlaces simbólicos o que, al menos, son preferibles en lugar de usar enlaces simbólicos. Su respuesta se aplica tanto a HL como a SL.

— Marcelo

3

BusyBox lleva esto al máximo.

— Max Ried

8

Cuando mi software P2P termina de descargar un determinado archivo, el archivo se coloca en un directorio específico. Los archivos descargados casi nunca necesitan ser editados. El caso común es que hago un enlace duro en un directorio diferente donde necesito que esté el archivo.

Ventajas:

Todavía comparto el archivo en la red P2P como debería, incluso si yo rmo mvla "copia".
El archivo también está en la ruta donde lo necesito; La mayoría de estos lugares no se comparten.
Puedo rmel "original" para dejar de compartir el archivo; Esta operación no afecta la "copia" en el lugar deseado.
Mi espacio en disco se usa solo una vez.

El punto principal: si supiera de antemano qué archivo haría rmprimero, podría utilizar el enlace simbólico. Pero nunca se.

— Kamil Maciorowski
fuente

6

Los sistemas de archivos son una forma simple pero eficiente de organizar y clasificar archivos (esta es su razón principal de existencia). Los enlaces duros permiten un mayor grado de flexibilidad en este asunto.

Como se mencionó, no existe un concepto de original y copias cuando se trata de enlaces duros, todas las entradas de directorio (enlaces duros) son simplemente referencias a la existencia del archivo (señale su inodo) sin prioridad, por lo tanto, tampoco hay enlaces duros rotos. .

Así que aquí hay algunos de los casos de uso que atienden los enlaces duros, pero los enlaces blandos no :

Imagine que tiene una colección de películas o música u otros medios y desea que se apliquen diferentes criterios de clasificación, como canciones clasificadas por artista en una rama (cada artista tiene su propio subdirectorio); por género en otra rama (cada una en un subdirectorio diferente), etc. Aún así no desea duplicar los archivos ni decidir dónde colocar el "original" para que tenga la libertad de reclasificar sin tener que " administrar "y volver a vincular archivos cuando se mueve para evitar enlaces rotos.
Otra razón es evitar el desperdicio de espacio de almacenamiento que se requeriría para tener múltiples copias del mismo archivo y, sin embargo, permitir que la chrootllamada al sistema se beneficie de un subconjunto de archivos en la raíz del sistema de archivos "maestro" (los enlaces simbólicos nunca podrían hacer referencia a archivos externos) la chrootcaja de arena, incluso si tienen rutas relativas).
Otra razón muy importante pero raramente mencionada para que existan enlaces duros son los ..subdirectorios. Los ..directorios en realidad son (en la mayoría de las implementaciones de Unix fs) enlaces duros al directorio padre, sin enlaces duros esto tiene que implementarse de una manera completamente diferente, mientras que la existencia de enlaces duros hace que esto sea muy fácil de implementar.

— Marcelo
fuente

1

Para el punto 1, usar uuids como el nombre 'canónico' para los archivos, y hacer que todos los nombres legibles por humanos sean enlaces simbólicos a los uuids, es una solución alternativa.

— R ..

Aunque la sugerencia de uuids suena académicamente correcta, usar uuids para nombres de archivos no suena muy práctico, y nuevamente, el objetivo es simplificar las cosas, no hacerlas más difíciles o "menos comprensibles para los humanos". Además, tener uudis para la referencia de archivo "canónico" sería una indirecta adicional al inodo real del archivo, por lo que no tiene sentido lograrlo en este enfoque ya que no ofrece ventajas, solo desventajas como: impacto en el rendimiento, adicional espacio en disco para almacenar más entradas de directorio, con un montón de archivos con nombres "extraños" alrededor ...

— Marcelo

5

Un ejemplo muy común en el mundo real que necesita enlaces duros:

git clone --reference <repository>

Esto se clona desde un repositorio local de Git con casi cero copias. En lugar de copiar los archivos de objetos (archivos inmutables utilizados por Git para su "base de datos"), simplemente los vincula.

Cualquier repositorio puede eliminar un objeto, pero el inodo permanece válido para el resto de los repositorios. Y si un objeto se elimina de todos los repositorios, se elimina del disco. Los enlaces duros son una solución hermosamente robusta y rápida. Muy común en servidores CI.

Existe una versión no dura-link: git clone --shared <repository>. Esto, sin embargo, es voluble y tiene muchas más advertencias ya que todos están trabajando en el mismo directorio.

— Paul Draper
fuente

4

Recientemente tuve un caso de uso para un procedimiento de actualización algo seguro para sistemas basados en U-Boot donde uImagehay un enlace suave que apunta a la imagen para arrancar, la idea era que un corte de energía no planteara problemas, sin importar en qué punto del proceso ocurre (suponiendo que el sistema de archivos se reproduce):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Sin enlaces duros no sería tan simple.

/editar:

Gracias a los comentarios ahora sé que sería mejor hacerlo:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(El rmestá aquí para poder escapar mejor de un estado extraño, por ejemplo, si uImagees algo inesperado que haría mvfallar [pero no necesariamente la ln -sfsolución anterior ]).

— phk
fuente

2

+1 porque conceptualmente es una muy buena razón, pero desafortunadamente ln -sfno es atómica. Elimina el viejo enlace simbólico y crea uno nuevo. Para solucionar esto, debe crear un nuevo enlace simbólico con un nombre temporal y rename(2)( mv) para nombrar el que desea reemplazar.

— R ..

@R .. Tienes razón! 😲 stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")

— phk

1

Por cierto, mira aquí mi versión de install.sheso resuelve el problema: git.musl-libc.org/cgit/musl/tree/tools/install.sh

— R ..

@R .. Tenga en cuenta que mvincluso con -fpodría fallar si el destino ya existe como, por ejemplo, un enlace simbólico que forma parte de un bucle de enlace simbólico. Demostración:

ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar

— PHK

3

Un uso que he tenido para los enlaces duros es al descargar o descomprimir un archivo roto. El programa que descarga o descomprime (como descomprimir o descomprimir) a menudo eliminará automáticamente el archivo incompleto cuando encuentre un error, y generalmente no hay opción para conservarlo. Si quiero mantener el archivo, puedo hacer un enlace duro a él.

— Thomas Padron-McCarthy
fuente

3

BackupPC es un sistema de respaldo que utiliza enlaces duros en los servidores para proporcionar deduplicación a nivel de archivo.

Los archivos se almacenan primero en un árbol de directorios "pool" en función de su hash md5. Cualquier copia de seguridad que haga uso de ese archivo crea un enlace rígido al archivo del grupo. A medida que las copias de seguridad caducan / se eliminan, sus enlaces duros se eliminan del sistema de archivos.

Los enlaces duros son superiores a los enlaces blandos aquí porque proporcionan un conteo automático de referencias. Un trabajo cron elimina periódicamente los archivos en el directorio del grupo que no tienen más de un enlace.

Este método tiene algunas desventajas (principalmente, que es difícil usar herramientas basadas en el sistema de archivos para replicar el almacén de copias de seguridad), pero se ha demostrado que es bastante robusto en la práctica.

Otro caso de uso: el servidor de aplicaciones web tomcat java trata los nombres de archivo como metadatos. Se debe nombrar un archivo "war" de Java en función de su ruta en el servidor web.

por ejemplo: foo.war es el código de Java que sirve a la URL/foo

Desafortunadamente, resuelve los enlaces simbólicos antes de tomar esta decisión.

Por lo tanto, supongamos que desea implementar una compilación de la aplicación y asígnele un nombre de archivo descriptivo (por ejemplo, con un número o fecha de lanzamiento). No puede hacer un enlace simbólico al archivo con el nombre "real": debe crear un enlace duro.

foo.warenlazado a foo-20170129.warno funciona

foo.warvinculado a las foo-20170129.warobras.

No me gusta este comportamiento de Tomcat, pero los enlaces duros me dan una forma de evitarlo.

— Dan Pritts
fuente