Perché c'è poco uso della condivisione di file come compressione (al di fuori delle librerie)?

0

Recentemente stavo cercando un programma che funzionasse come un demone e trovassi i file che hanno lo stesso tipo di dimensione / tipo, controlla se sono uguali, quindi rendi entrambi un hard link a una singola copia, se lo sono. E ho iniziato a chiedermi perché i sistemi operativi non lo fanno automaticamente.

Ho pensato che forse sarebbe stato dispendioso in termini di tempo, ma non sarebbe stato necessario verificare se non fossero stati aggiunti nuovi file all'esterno della directory della cache e il controllo della dimensione avrebbe ridotto rapidamente lo spazio di ricerca. Poi ho pensato forse perché non si presenta molto spesso; ma se così fosse, mi aspetterei che le console di gioco facciano questo, perché molti giochi useranno lo stesso pacchetto di effetti sonori, ad esempio, ma non lo fanno. Avere due giochi di una serie richiede la stessa quantità di spazio sufficiente per sommare le due dimensioni, anche se sarebbero riutilizzate tonnellate di risorse.

O in un sistema come YouTube, controllano i video rispetto ad altri video quando controllano le violazioni del copyright, ma non sembrano causare la memorizzazione di due video identici una sola volta, considerando il modo in cui il mirroring di un video può impedire che venga rimosso il sito, (ad es. quando "youtube vs users" è stato specchiato, lo hanno rimosso dai risultati della ricerca anziché continuare a portarli fuori dal sito).

Quindi, qual è il motivo per cui il sistema non comprime le cose in questo modo?

    
posta Patrick Jeeves 06.01.2015 - 17:36
fonte

4 risposte

11

Si chiama deduplicazione.

Alcuni filesystem lo fanno (come ZFS), alcuni sistemi di storage a livello di blocco lo fanno (come NetApp), alcuni sistemi di backup lo fanno (rsnapshot), i sistemi di gestione del codice sorgente lo fanno (Git, bzr, fossile)

Non è così raro, solo che fino a poco tempo fa era una scelta costosa per i file system generici.

Si noti che non è una buona idea farlo come suggerito (hardlink) per i volumi di uso generale, poiché la modifica di una "copia" modifica anche l'altro. Dovresti occuparti prima di interrompere il collegamento. Alcune applicazioni non "modificano" mai i file, invece su ogni "salvataggio" viene creato un nuovo file e successivamente viene rinominato per sostituire l'originale. In quei casi sì, sarebbe ragionevolmente sicuro tenere i collegamenti fisici; ma vuoi controllare ogni applicazione che usi sui tuoi file? Molto più semplice è tenere separate le copie separate

    
risposta data 06.01.2015 - 18:50
fonte
2

Ci sono filesystem che fanno questo, btrfs o ZFS per esempio. Non (solo) per i file, anche per le singole estensioni.

Dropbox fa anche questo (o almeno lo usa). Caricare un file di grandi dimensioni che un altro utente ha già caricato richiede solo una piccola quantità di tempo, perché in realtà non è caricato. Il client invia un hash del file al server e quando il server conosce già il file, dirà al client di interrompere il caricamento.

    
risposta data 06.01.2015 - 19:47
fonte
1

Il problema è che, facendo ciò in background, stai cambiando la semantica della mutabilità del sistema in un modo che la gente non si aspetterebbe.

Considera il seguente flusso di lavoro:

  1. Creo una meravigliosa opera d'arte in myasciidrawing.txt .
  2. Decido che voglio creare un'opera d'arte simile, quindi copio myasciidrawing.txt in awesomeasciidrawing.txt e inizi a modificarlo.
  3. Qualche tempo dopo, felice della mia creazione, l'ho salvato.
  4. Più tardi torno a guardare myasciidrawing.txt e trovo che ha il contenuto di mynewasciidrawing.txt e ho perso l'originale!

Quello che è successo è che tra 2) e 3) la meravigliosa routine di deduplicazione in background che ha rilevato che myasciidrawing.txt e awesomeasciidrawing.txt hanno gli stessi contenuti, deduplicati e collegati, in modo che quando ho salvato awesomeasciidrawing.txt è ovewrote myasciidrawing.txt troppo!

Peggio ancora, è che se myasciidrawing.txt e awesomeasciidrawing.txt hanno lo stesso contenuto dopo il passo 3 dipende da quale software stai usando per modificare.

Se utilizzi software che modifica l'originale in posizione, i collegamenti significano che entrambi sembrano essere modificati contemporaneamente. Se il software rinomina il vecchio file '.bak' e poi scrive un nuovo file con lo stesso nome, allora myasciidrawing.txt e awesomeasciidrawing.txt.bak conterranno entrambi il disegno originale, ma awesomeasciidrawing.txt punterà al contenuto aggiornato.

Questo è uno dei motivi per cui la deduplicazione dei filesystem tende ad usare la semantica copy-on-write , poiché ogni dato deduplicato è, per definizione, dati condivisi.

    
risposta data 06.01.2015 - 19:17
fonte
0

Presumo che tu intenda i file del tipo di risorsa qui, ad es. immagini, canzoni, suoni, ecc. Se si parla di condivisione di codice eseguibile, questo percorso è già stato ben battuto: windows ha avuto la sua DLL L'inferno mentre Unix aggira questo problema compilando un eseguibile di tutti i canti e balli.

Il problema principale con i file di tipi di risorse nella mia mente viene fornito con il montaggio. Diciamo che hai una foto e vuoi fare una copia per ritagliarla, correggerla, migliorarla ecc. Chiaramente non vorrai che la modifica aggiorni anche la fonte in quanto le informazioni non elaborate andrebbero perse.

C'è qualche chilometraggio in applicazioni che farebbe un lavoro del genere - per controllare librerie fotografiche e amp; collezioni musicali ecc. Ma non vedo il valore nel costruire questo nel sistema operativo come standard.

Ricorda anche che alcuni sistemi operativi non hanno la possibilità di creare file collegati con la stessa eleganza di Unix.

    
risposta data 06.01.2015 - 17:54
fonte

Leggi altre domande sui tag