Svantaggi per la creazione/la rimozione di molti collegamenti duri?

Question

Devo creare centinaia di migliaia di collegamenti temporanei duri o simbolici che verranno eliminati poco dopo la creazione. Per i miei scopi, entrambi i tipi di collegamenti funzionano (cioè l'obiettivo non è una directory ed esiste sempre sullo stesso file system)

A quanto ho capito, i collegamenti simbolici creano un piccolo file che contiene il percorso del file originale. Mentre un hardlink crea un riferimento ai dati nello stesso inodo. Quindi forse se ho intenzione di creare/eliminare migliaia di questi collegamenti, è meglio creare ed eliminare migliaia di piccoli file (collegamenti simil) o migliaia di questi riferimenti (HardLink)? Sembra che si fisca il disco rigido (forse frammentazione) mentre l'altro potrebbe tassare il file system stesso? Dove vengono archiviati i riferimenti ade. Rischedo di corrompere il file system creando così tanti collegamenti difficili? E la velocità?

Grazie per la tua esperienza!

Questo è un lavoro in grado di utilizzare FFMPEG per codificare un film da un sottoinsieme arbitrario di immagini da una directory. Poiché FFMPEG richiede che i file vengano denominati correttamente (ad esempio frame%04d.jpg) mi sono reso conto che posso semplicemente creare collegamenti Hard/Sym al sottoinsieme dei file e solo nominare i collegamenti in modo appropriato. Ciò evita di rinominare i file originali e dover copiare effettivamente i dati. Funziona alla grande ma richiede di creare ed eliminare ripetutamente molte migliaia di collegamenti.

Una sorta di risolvere anche questo problema, credo:convertire la sequenza di immagini usando ffmpeg

Answer 1

Se questa attività rompe il file system, il file system è in errore, non tu. I file system sono generalmente piuttosto affidabili, quindi non preoccuparti.

Entrambe le opzioni richiedono l'aggiunta di una voce nella directory. Il collegamento simbolico richiede anche la creazione di un file. Quando si accede al file, il collegamento hard salta direttamente al contenuto, mentre si accede a un sintesi richiede di trovare il file symlink, leggerlo, trovare la directory con il contenuto, trovare dove si trova il contenuto e quindi accedervi. Pertanto, i collegamenti simbolici sono più lavoro per il filesystem tutt'intorno.

Ma la differenza è minuta rispetto al lavoro di leggere effettivamente i dati nei file. Pertanto non mi preoccuperei, e vado solo con qualunque cosa ti dà meglio la semantica che desideri.

Answer 2

Dal momento che non stai cercando di creare centinaia di migliaia nello stesso file, i collegamenti duri sono marginalmente migliori.

Tuttavia, i collegamenti simbolici in /TMP if /TMP sono TMPFS sono ancora meglio eseguiti.

Oh, e i collegamenti simbolici sono troppo piccoli per causare problemi di frammentazione.

Answer 3

Entrambe le opzioni richiedono l'aggiunta di una voce di file nella directory inode, la struttura della directory può crescere allocando nuovi blocchi.

Ma un collegamento simbolico richiede l'allocazione di un inode e il filesystem ha un limite per gli inodi. Tuo centinaia di migliaia I collegamenti simbolici possono colpire questo limite e potresti ottenere il "Non abbastanza spazio per il file" Messaggio di errore anche con gigabyte gratuitamente.

Per impostazione predefinita, lo strumento di creazione del file system scegli il numero massimo di inodi in base alla dimensione della partizione fisica. Ad esempio per Linux Ext2/3/4, mkfs.ext3 usa un bytes-per-inode rapporto che puoi trovare nel tuo /etc/mke2fs.conf.

Per un filesystem esistente, ecco un comando per ottenere informazioni sugli inodi:

# dumpe2fs /dev/sda1 | grep -i inode | less

Inode count:              979200
Free inodes:              742304
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       441066
Journal backup:           inode blocks

Come conclusione, dovresti Preferisci collegamenti difficili Principalmente per il consumo di risorse sul disco e in memoria (strutture VFS nelle cache).

Un altro consiglio: non creare troppi file nella stessa directory, i file 2'000 sono un limite ragionevole per evitare problemi di prestazioni.