Domanda

Mi sono imbattuto in questo articolo su crittografia del disco rigido basata su hardware e ho capito che questo non solo avrebbe offerto un ottimo modo per proteggere i tuoi dati, ma avrebbe anche accelerato le applicazioni che utilizziamo per crittografare tali dati.

Questo mi ha portato a chiedermi...

Sarebbe possibile fare la stessa cosa per la compressione in modo che tutti i dati vengano compressi o decompressi in modo appropriato mentre vengono letti e scritti sull'unità?

Non ho programmato il firmware da un po' di tempo, quindi non sono nemmeno sicuro che sia tecnicamente possibile.

Se lo fosse, tuttavia, probabilmente potrebbe offrire un po' più di spazio di archiviazione alle persone.

Quali sono i pro e i contro della programmazione di tale approccio da utilizzare nel firmware?

È stato utile?

Soluzione

Nel mondo delle unità da 1 TB per una velocità di $ 100 è una risorsa molto più preziosa dello spazio. Non ne varrebbe la pena.

EDIT:

Ah, quindi stai dicendo che sarebbe più veloce catturare 100 byte di dati compressi dai piatti, decomprimerlo e quindi inviarlo insieme al sistema invece di catturare 800 byte di dati non compressi e inviarlo insieme al sistema perché i tempi di ricerca sono così lenti.

Sembra un approccio intelligente, ma sono disposto a scommettere che se il compromesso finisce per valerne la pena, i produttori di dischi rigidi hanno già utilizzato questa tecnica e le velocità del disco rigido sono ciò che sono nonostante il fatto.

Ma chissà, potresti essere su qualcosa!

Altri suggerimenti

Ricordo circa 15 anni fa di aver visto un annuncio per una scheda controller IDE che avrebbe comportato la compressione hardware. Non sono sicuro se fosse buono o no. Erano i giorni in cui le unità da 1 GB superavano i $ 1.000.

Chi si ricorda di Stacker? Tutto ciò era già fatto a morte negli anni '80 / '90 . La velocità non è mai stata un problema, e nemmeno & Quot; difficile. & Quot; Al giorno d'oggi è completamente inutile.

Come detto in precedenza, il guadagno non è così grande, specialmente se si stanno comunque archiviando file con accesso raro in una forma compressa.

Come sarebbe difficile fare nell'hardware (quali dimensioni del disco dovrebbero essere riportate? Cosa fai se l'entropia dell'ingresso è uguale alle sue dimensioni?) e le moderne CPU + RAM sono incredibilmente veloci rispetto agli HDD, comunque nel software.

Un'implementazione che conosco è compFUSed che è sovrapposta a qualsiasi altro file system, un altro è ZFS voce del blog su come abilitarlo che supporta la compressione in modo nativo.

Avevo pensato anche a questa idea un po 'di tempo fa per il traffico di rete, che è stato fatto in precedenza: ci sono carte acceleratrici per il comressing usando gzip: http://www.aha.com/show_prod.php?id=36

Avevo anche pensato che un altro vantaggio sarebbe che ora è possibile trasferire senza comprimere i contenuti dall'unità: è sufficiente leggere dal disco i blocchi compressi e inviare invece di doverli comprimere in un secondo momento.

È possibile, ma è molto, molto complicato.Dovrai sviluppare driver personalizzati perché mentre i settori crittografati hanno le stesse dimensioni dei settori normali, e quindi utilizzano la stessa matematica per trovare i dati, i settori compressi sono "più piccoli", quindi devi tenere una mappa dei settori "reali" per settori compressi nel sistema operativo o sull'unità stessa.

L’unico altro aspetto è la velocità di accesso e la latenza.Non dovrebbe influire sulla ricerca, ma potrebbe essere necessario più tempo per comprimere i dati rispetto a scriverli: la compressione richiede un'elaborazione piuttosto intensiva.

Inoltre, la compressione non è ottimale finché non si ottengono grandi quantità di dati.Probabilmente puoi comprimere 512 byte (1 settore) al volo e ottenere in media una compressione di una piccola percentuale, ma le persone vogliono davvero vedere una compressione del 20% e più prima di essere disposte a spendere soldi extra per l'hardware.

Richiederà maggiore potenza di elaborazione del disco e memoria, il che aumenterà il costo dell'unità.

Inoltre, la capacità delle unità sta crescendo a un ritmo tale che probabilmente non è conveniente farlo.

Diciamo, ad esempio, che sviluppi la compressione miracolosa che raddoppia lo spazio senza calo delle prestazioni, senza driver aggiuntivi (instabili o soggetti a crash), funziona su qualsiasi sistema operativo, ecc.Ma aggiunge $ 100 al costo dell'unità.

Potrebbe avere senso che qualcuno lo faccia ora per un'unità da 1 TB, convertendola in un'unità da 2 TB, ma tra 6-8 mesi le unità da 2 TB saranno inferiori a $ 200.Non ne varrà la pena per un'unità più piccola, perché ora puoi ottenere un 1 TB per $ 99.

Se lo hai fatto in modo che funzioni tra l'unità e il computer, avrai una latenza molto maggiore rispetto all'installazione diretta nell'unità e il rapporto prezzo/prestazioni potrebbe non valerne la pena.

Quindi tecnicamente è possibile, ma presenta insidie ​​e aggiunge complessità e punti deboli al sistema, ma anche se non presentasse questi inconvenienti, è probabile che non ne valga la pena.

-Adamo

Un'altra considerazione è che la maggior parte dei file di grandi dimensioni sul disco (musica, immagini e video) di solito sono già compressi (MP3, JPEG, MP4 / MOV), quindi la compressione non li aiuterebbe. E i file che non sono compressi (file di testo, elaborazione testi, testo di e-mail) tendono ad essere una goccia nel secchiello.

Mi stavo chiedendo la stessa cosa perché stavo cercando tra migliaia di file di testo compressi con gzip, e decomprimendo pioli il mio quad-core i7, e mi chiedevo se l'hardware gzip dedicato potesse accelerarlo come una GPU accelera l'elaborazione parallela. Ma sospetto che le preoccupazioni di cui sopra lo farebbero in modo che per la maggior parte degli usi un disco rigido compresso non sarebbe di grande aiuto.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top