Quote:
Originariamente inviato da rockroll
Questa della mancata deduplication mi è nuova: se riscrivo lo stessso file, non recupera lo spazio, quindi alla fine mi potrebe dire che il disco è pieno anche se è quasi vuoto?
|
Se il file system non ha la deduplication, ogni file viene gestito come una cosa a sè, quindi una copia di un file occupa lo stesso spazio su disco che il file originale.
Non è che il disco è "quasi vuoto", il disco è pieno di copie dello stesso identico file.
I file system di nuova generazione gestiscono la deduplicazione comunque non a livello di file ma di blocco di dati, ogni file viene scritto come tanti blocchi di dati in un file system.
Questo gli permette di fare deduplication anche su file completamente diversi, visto che dove trovano 2 o più blocchi di dati uguali (magari corrispondenti a parti diverse del file, chissenefrega), rimappano tutto su 1 blocco fisico sul disco e gli altri li tolgono.
Oppure se abbiamo un file grosso formato da sequenze ripetute. Ogni volta che lo stesso file presenta la stessa sequenza ripetuta a livello di blocco, quei blocchi vengono rimappati su uno e gli altri spariscono.
In questo modo si avrebbe anche un effetto simile alla compressione, per quanto l'effetto dipende molto dal tipo di file.
Ma si parla di database o documenti, quindi all'utente medio frega poco.
Quote:
E se prima deleto poi scrivo, che dovrebbe essere equivalente...
|
Se cancelli il file di partenza sparisce e hai solo la copia, quindi lo spazio occupato è solo quello della copia.
Quote:
il data deduplication può aiutare perché in evita al costo di utilizzare la cpu per i calcoli di copiare gli stessi dati,
|
La dedup carica il processore, visto che per sapere se un blocco è già scritto o no deve fare dei checksum o comunque far girare algoritmi per capirlo.
Se il file system implementa la dedup PRIMA della scrittura dei dati (quindi nella cache di scrittura nella RAM), diminuisce il traffico da/verso i dischi, perchè tutti i dati già presenti non li torna a scrivere ma scrive solo dei link ad essi.
Quindi copiare file di grosse dimensioni all'interno della stessa partizione è dannatamente rapido, visto che nella realtà non sta copiando una mazza ma solo mettendo dei link in giro agli stessi dati.
In genere, il processore è molto più veloce del disco in questa operazione, quindi conviene.
Anche la compressione citata sopra ha lo stesso scopo, cioè ridurre il traffico da/verso i dischi, non tanto occupare meno spazio.
Nella maggioranza dei casi, il processore comprime/decomprime un file molto più velocemente del tempo che ci mette un disco a leggerlo/scriverlo.
Quote:
inoltre come ha già scritto bob..... è utile soprattutto nel caso si faccia uso di diverse virtual machine,
|
O anche per sistemi di versioning, cioè che tengono automaticamente e in modo trasparente e SICURO (dagli utonti) uno storico dei file che sono stati modificati nel tempo per permetterti di tornare alla versione precedente con facilità senza doversi sbattere a fare copie a mano ogni nuova modifica e chiamarle nel tradizionale modo stupido e inutile a posteriori come
-documento1
-documento1new
-documento1new1
-documento1new1new
eccetera, che appena li copi in blocco perdi la data di modifica quindi poi quale di questi è la versione in data X?
In questo caso, hai file che sono composti in (gran) parte da roba che c'è già (quindi rimappata), e in parte da roba nuova.
Ad esempio Dropbox che tiene uno storico di 30 giorni di modifiche ai file con possibilità di tornare indietro. O anche OwnCloud che lo fa in locale.