Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 71, views: 35.479 •

Tijdens de Flash Memory Summit, die deze week in Santa Clara plaatsvond, heeft LSI de nieuwste technieken voor zijn SandForce-controllers voor solid state drives gedemonstreerd. Het bedrijf liet onder meer een techniek voor virtuele ssd-capaciteit zien.

LSI is producent van een van de meest gebruikte controllers die in solid state drives gebruikt worden: de SandForce 2000-serie. Het bedrijf werkt al een tijd aan een opvolger van die controller, die in toekomstige generaties solid state drives gebruikt moet worden. Met een nieuwe controller om het nand-geheugen aan te sturen worden ook diverse nieuwe technieken ontwikkeld. LSI demonstreerde een feature die de virtuele capaciteit van een ssd groter kan maken dan de fysieke capaciteit. In de praktijk zou zo meer dan de maximale capaciteit van een ssd aan data opgeslagen kunnen worden.

De techniek wordt LSI DuraWrite Virtual Capacity, kortweg DVC, genoemd. Volgens LSI kan met DVC-technologie tot driemaal meer data opgeslagen worden dan de capaciteit van een ssd aangeeft. Voor de demonstratie werd een controller uit de SF2000-serie gebruikt, waarmee een 120GB-ssd werd aangestuurd. Volgens Windows was op dat systeem 175GB aan data opgeslagen, met nog bijna 63GB vrije ruimte, voor een totale capaciteit van 238GB. Het is echter nog niet duidelijk of deze techniek, die primair is bedoeld voor datacentra waar met veel comprimeerbare data gewerkt wordt, ook naar consumentenproducten komt.

Naast de DVC-techniek toonde LSI ook een verbeterde foutcorrectiemethode met een techniek die Shield gedoopt werd. Foutcorrectie wordt steeds belangrijker naarmate kleinere flasharchitecturen gebruikt worden en moet ook de levensduur van de ssd's verlengen. Ten slotte liet LSI een update voor zijn SandForce 2000-controllers zien. De nieuwste generatie moet overweg kunnen met Toshiba's tweede generatie 19nm-nandchips.

LSI's DVC-technologie in actie

Reacties (71)

Ik vraag me dan wel af hoe hier op besturingssysteemniveau mee wordt omgegaan, als het besturingssysteem geen weet heeft van deze feature op filesystemniveau, kan dit voor rare taferelen worden qua rapportage van vrije ruimte e.d.... immers is niet van tevoren bekend hoe goed comprimeerbaar de data gaat zijn.
op zich niet zo belangrijk
Windows gebruikt sinds ntfs 4 (niet zeker van de versie) de mogelijkheid om directory's te linken naar andere directory's op dezelfde partitie of andere
van zodra je dat doet (en dat doet Windows standaard in bijvoorbeeld winsxs) klopt het nooit exact meer
bij mijn weten is dat nooit een probleem geweest
De rapportage is niet zo boeiend op zich maar wat gebeurt er als de disk 'vol' zit wegens minder comprimeerbare data dan verwacht maar het filesystem, ingericht op een bepaalde grootte disk, nog niet?
Ik gok dat enkel de fysieke ruimte wordt getoond als zijnde beschikbaar en dat na het overzetten van data Windows opnieuw aan de ssd zal opvragen hoeveel ruimte er dan nog vrij is. Waarschijnlijk gebeurt dat laatste nu ook al.
Een combinatie van compressie en het langzaamaan terugschroeven / vrijgeven van de veiligheidsmarges op je schijf, als de controller doorkrijgt dat je een normale tot weinig behoevende gebruiker bent. Schrijf je daarentegen heel veel, dan houd je de oorspronkelijke grote. Slimme techniek, maar een schijf die van maand tot maand van grootte kan variëren kan wel even wennen zijn.

Het is raar dat zakelijke gebruikers, die wel gewend zijn dat SSD schijven kunnen uitvallen, hier het meeste aan hebben, maar dan is de vraag wie gebruikt SSD voor langdurige opslag? Juist voor een consument, die naar bang per buck kijkt en niet altijd veel schrijft, zal het nog wel even duren voordat de besturingssystemen dynamische schijfgroottes ondersteunen.

[Reactie gewijzigd door paknaald op 16 augustus 2013 16:31]

In je laatste zin stel je het probleem al vast: Windows *) moet op het moment van partitioneren al weten hoe groot de schijf is. Daarom valt er niks "langzaam vrij te geven".

Hoe dit onder Linux-achtige OSen precies zit weet ik niet, maar het screenshot is van een Windows-bak, vandaar dat ik daar op reageer.

*) Dit geldt in elk geval de consumentenversies; met Windows Server heb ik niet genoeg ervaring om te weten wat voor extra trucjes die ondersteunt. Van de andere kant, ik vermoed dat dit niet zozeer een beperking van Windows is, als wel van NTFS zelf.
volumes expanden en shrinken kan perfect zelfs met de pro versie van windows 7 en de primaire doelgroep zijn toch datacentra, dus die zullen al helemaal geen last hebben van softwarebeperkingen voor een consumer-OS
Gewoon hardwarematige compressie dus? lekker terug naar de goede oude tijd van drivespace, doublespace, speeddisk, etc. Van vrije ruimte klopt geen snars meer, en maar afvragen waarom je je filmpje niet weg kunt schrijven ondanks dat je genoeg ruimte vrij zou hebben. Kun je beter gewoon NTFS compressie gebruiken.
En hoe nadelig is dit voor bv latency en energieverbruik van de SSD's? Er moet toch compressie plaatsvinden op de achtergrond.
Eén groot voordeel: Met NTFS compressie is je processor druk.
Als SandForce compressie met een minimale performance hit kan garanderen zijn we één van de grootste problemen uit de drivespace-tijd kwijt.
Minimaal, mede door caching op zowel de disk als gewoon RAM.
Verder hebben we tegenwordig CPU time genoeg.. IO is al best lang bottleneck, dus ik offer graag CPU op voor wat RAM
Tijdens dat comprimeren gaat er waarschijnlijk ook aardig wat data heen en weer over je memory bus, dus zit je niet alleen de CPU te belasten... Dat verhaal gaat dus niet op.
De controler in de SSD doet comprimeren. Dus geen performance hit op andere onderdelen. Dat deden sandforce controlers toch al (of in iedergeval ontdubbelen).

Toch zullen veel mensen wantrouwend naar sandforce controlers blijven kijken. Zeker nu ze weer meer compressie en features in bouwen. Intel heeft laten zien dat het wel mogenlijk is een betrouwbare SSD met sandforce te maken. Maar lange tijd had vrijwel alles met sandforce controlers betrouwbaarheidsproblemen.
Je CPU zit de meeste van de tijd toch maar te wachten op het antwoord van een blockdevice. Zoveel invloed heeft compressie en decompressie niet meer op je CPU. ZFS en gelijk soortige werken ook al met compressie en wel om meer data te kunnen verplaatsen, dan de disk(s) aankunnen.

En idd, denk je nog 6GB vrij te hebben, pas je film van 2GB er niet meer op. Dit is iets je al helemaal niet in een DC wilt hebben.
Afhankelijk van wat je met die CPU doet. Als je veel met video bezig bent is het toch echt andersom.
SSD schijven geven tegenwoordig indicaties af van 550/520MB lezen/schrijven per seconde. Dan moet je toch al wel een aardig cpu blokje hebben wil je dat in real time gaan in/uitpakken. Persoonlijk lijkt mij dit een zeer zinvolle uitvinding. Als het hardware circuit voor in/uitpakken sneller is dan het opvragen van blokken op de SSD zou het zelfs een snellere SSD kunnen opleveren. ( omdat er minder blokken gelezen/geschreven hoeven te worden voor dezelfde data ) de extra capaciteit is dan mooi meegenomen.

Maar denk ook eens aan games. Op dit moment bevatten games grote gecomprimeerde data libraries die tijdens het laden of gebruik ervan uitgepakt moeten gaan worden. Met de bovenstaande techniek zou het mogelijk worden dat games al hun data zonder compressie op de schijf weg gaan schrijven. ( game moet dit uiteraard dan ondersteunen ) De schijf zelf verzorgt nu de compressie/decompressie en haalt dus CPU verbruik weg tijdens het spelen.

Het is maar net hoe creatief je bereid bent na te denken. ;)

[Reactie gewijzigd door MoonWatcher op 18 augustus 2013 10:48]

Daar lijkt het wel op, comprimeren van de data, zelfde functie die we al kennen vanaf win98 maar nu word het gedaan door de controller ipv de cpu.

We weten ook dat geschatte grote daarom ook maar met korreltje zout moet nemen, probeer er maar 238GB aan MP3's of zo op te zetten dan zul je waarschijnlijk niet gaan halen, zal wellicht maar net iets meer dan 120GB(of zelfs bijna helemaal niks in ergste geval) op passen. En vul voor MP3 maar elke andere comprimeert type bestand in, zoals jpg, divx, winrar, etc.

Al dat soort bestanden hebben al compressie en zullen dus maar minimaal kleiner kunnen, zijn allemaal al comprimeert. Of moet iets drastisch zijn veranderd.
Sinds MS-DOS 6 zat het zelfs al in het OS, daarvoor had je al programmas als Stacker. Ongetwijfeld bestond het principe daarvoor ook al.
Het zat niet direct in het OS, er werd een aparte driver en applicatie meegeleverd met het OS.
Duh, zo werkte heel MS-DOS. Dat had zelfs een driver nodig voor >640kB geheugen. En zelfs Windows 8 nu heeft drivers voor standaard SATA disks, dus veel is er niet veranderd.

Back on-topic: vrij zinloos feature. Zoveel comprimeerbare data heb je niet, en bovendien heeft NTFS een uitstekende ingebakken mogelijkheid.
En daarom is dit juist zakelijk interessant. Zeker in een klassieke kantooromgeving heb je juist enorme hoeveelheden te comprimeren data, en nauwelijks gebruik van films en muziek.
Helemaal leuk wordt het als de controller intelligent genoeg is om een soort van single instance storage op blok-niveau kan doen; in dat geval wordt elk stukje herhaalbare data maar één keer opgeslagen wat enorme winsten kan opleveren.
Simpel voorbeeld: een verstuurde nieuwsbrief in PDF die 500 van de gebruikers op hun homedrive zetten. Deze hoeft maar 1 keer echt opgeslagen te worden. Met overhead erbij (pointers) neemt het bestand dan wellicht maar 2x de benodigde ruimte in beslag, i.p.v. 500x. In de praktijk hoeft dit mechanisme zich niet te beperken tot hele bestanden, maar kan dit toegepast worden op delen van bestanden. (Blokken data dus)
Je kunt je wellicht ook voorstellen wat voor een effect dit heeft op een verzameling virtuele disks waar allemaal hetzelfde OS op staat.

Overigens zit een dergelijke techniek standaard in Windows Server 2012, alleen wordt het dedupliceren daar scheukend uitgevoerd. Veel SAN systemen kennen een dergelijke techniek ook, op basis van standaard schijven, alleen moet daar vaak enorm voor worden bijbetaald om deze functie te kunnen activeren.

Interessant aandachtspunt is wel dat backupsystemen meestal wel weer de volle hoeveelheid data te verstouwen krijgen.
Voor de effecten op latency/energieverbruik kun je kijken naar huidige Sandforce-SSD's. Die doen namelijk ook al compressie/deduplicatie.

Sandforce z'n verkoopargument is ook altijd geweest dat het sneller werkt (zie benchmarks die null data lezen/schrijven en de onwaarschijnlijk hoge snelheden die ze altijd adverteren) en voor langere levensduur zorgt (ivm groei van overprovisioning dankzij deduplicatie). Nu hebben ze alleen blijkbaar een alternatieve invulling van het vrijgebleven NAND gevonden: in plaats van het in te zetten als extra overprovisioning, kun je 't aan de gebruiker teruggeven.
misschien is het wel deduplicatie op block niveau ofzo. het hoeft niet compressie te zijn ...
Speed Disk is een defragmentatieprogramma en hoort dus niet in je rijtje thuis.
Als ik de woordencombinatie "Sandforce SSD" less dan lopen de rillingen me over de rug. Ik heb zoveel defecte SSD's in handen gehad met een Sandforcecontroller dat ik enorm huiverig ben om nu nog weer er van gebruik te gaan maken.

Heeft iemand positieve ervaringen met de nieuwere Sandforcecontrollers of blijft het een gevalletje "afblijven"?
Ik gebruik al meerdere jaren een Sandforce (Vertex 2) en een Indilinx (Vertex), beide van OCZ. Nooit problemen mee gehad. Volgens mij komen de problemen voor een groot deel door slechte componenten en door incompatibiliteit met het mainboard. Om daar nu alleen de SSD controller de schuld van te geven lijkt me niet terecht. Er zijn meerdere oorzaken voor de grote uitval.

Overigens blijkt uit het artikel dat ze reservecapaciteit aan de gebruiker teruggeven, terwijl ze die voorheen toewezen aan de overprovisioning. Bovendien wordt pas na het opslaan van de data berekend hoe goed de opgeslagen data comprimeerbaar was. Op basis daarvan berekent hij de (waarschijnlijk hypothetische) vrije ruimte. Het is me alleen niet duidelijk hoe Windows omgaat met volumes die een variabele grootte hebben.

Maar inderdaad krijg je dan vroeger of later het Doublespace effect, of het effect van de hardwarecompressie voor tapestreamers. Gebaseerd op statistische gegevens zou de nieuwe data zou moeten passen, maar helaas... de gebruiker moet ook niet zo dom zijn om gecomprimeerde data op te slaan. Dat laat het artikel wel doorschemeren. Dit systeem lijkt me vragen om problemen, tenzij ze zelf weer een ruime marge hanteren.
Vraag een willekeurige webshop naar het aantal RMA's en je zult horen dat de Vertex2 ver boven het gemiddelde ligt. Incompatibel met veel mainboards is ook een gevolg van slecht testen. De Intel 320's uit die tijd hadden nergens last van. OCZ was in die tijd echt drama.
Mijn Intel 520 met sandforce doet t nog prima.
Intel heeft eigen firmware geschreven voor deze controller. Dat maakt een wereld van verschil.
Kingston SSDNow V300, met 3 jaar volledige garantie, draait super. (draait, hahaha)
Hhhm, de terugkeer van Stacker/Doublespace?

Doet me terugdenken aan mijn 3m "250 MB" tapes die eigenlijk 120 MB waren :) Lekker transparant voor de gemiddelde gebruiker...

[Reactie gewijzigd door sewer op 16 augustus 2013 16:40]

Ik will Qemm ook weer terughebben! :)

Dat gezegd, heel veel van mijn data is prima te comprimeren. (Veel html en tekst).
Maar mijn data staat natuurlijk niet op mijn C-schijf, net als bij de meeste Tweakers denk ik. Je SSD gebruik je voor je OS en programmas, daarnaast draait een SSHD of HD.
Maar goed, dit ding is ontworpen voor datacentra, en ik kan me goed voorstellen dat ze daar wel degelijk winst kunnen maken.
Dit zijn dus typisch de dingen die je door je host OS of filesystem moet laten uitvoeren. Dan heeft in het RAM gecahede zooi er ook meteen voordeel van.

De techniek van LSI zal ook wel alleen met NTFS werken omdat de drive kennis moet hebben van het filesystem om de schijf dynamisch te resizen. Behoorlijk lellijk als je het mij vraagt.

Wat zal er gebeuren als ik een schijf van 100GB pak?
Ik schrijf daar eerst 100GB comprimeerbare dat naartoe.
Ik schrijf file X naar het einde van de schiijf (bijvoorbeeld LBA 110000)
Ik vervang de 100GB comprimeerbare data door niet-comprimeerbare data.

Gaat het OS dan niet gigantisch over de zeik? Immers staat er een bestand op de schijf op LBA 111.000, maar de schijf is maar 100.000 LBA's groot...

Ik weet dat een LBA niet 1MB groot is, maar 4KB. Dat rekent echter minder makkelijk.
Die 100GB aan niet-comprimeerbare data zal je dan niet kunnen schrijven. Men zal er vermoedelijk een "omrekentabel" tussen hebben zitten gezien met het vervangen van bestanden data continu lijkt te verplaatsen.
Zit in een SSD niet sowieso al een mechanisme waarmee blokken kunnen worden afgekeurd (omdat ze te vaak beschreven zijn)? Zou dat mechanisme (dwz, de API met het OS) hier niet worden uitgebuit om deze compressie achter de schermen mogelijk te maken?
Dit is toch gewoon hardwarematige compressie en niets anders? Of misschien intern een blockgrote van 1 byte gebruiken ofzo? Dat kan ook best wat schelen.

De techniek zou mij zeer welkom zijn in iedergeval; voor bijvoorbeeld grote mailomgevingen waarbij alle attachments als flatfiles buiten de database gehouden worden; zou dit heel handig kunnen zijn.

Ben benieuwd naar verdere info; het is mij nog wat raadselachtig..
ik denk dat er wel een marge is ingebouwd, eerst proberen en dan melden of het gaat of niet.
Daar zal heus wel een soort buffel eerst voor gebruikt worden, of fysiek op ssd gereserveerd, of via een andere weg zoals cache of via het internet geheugen als men hier stuur programma's voor maakt.
Het probleem blijft dat je niet kan voorspellen hoe comprimeerbaar de in de toekomst weg te schrijven gegevens gaan zijn. Rapportage van vrije ruimte blijft dan altijd een schatting, en persoonlijk wil ik dat een systeem nauwkeurige cijfers en gedrag geeft.
En wat als het gewoon slim werkt, en de vrije ruimte ook 1:1 echt vrij is...

Op dag 1 geeft ie aan 120GB, vervolgens zet jij er 50GB op wat gecomprimeerd maar 20GB is, vervolgens geeft het systeem aan dat er nog 100GB vrij is, wat er ook ECHT vrij is gezien er maar 20GB van de 100GB in gebruik is. Op dat moment heb je dus in windows een schijf van 150GB vaarvan 50GB in gebruik is...

Zo hoeven ze niks te voorspellen! Je ruimte groeit dus enkel aan wat je al hebt bespaard met compressie, en zo kan je nooit meer data er op zetten dan dat ding ook daadwerkelijk aan kan.
En wat als het gewoon slim werkt, en de vrije ruimte ook 1:1 echt vrij is...
Het artikel spreekt dat al tegen.
Voor de demonstratie werd een controller uit de SF2000-serie gebruikt, waarmee een 120GB-ssd werd aangestuurd. Volgens Windows was op dat systeem 175GB aan data opgeslagen, met nog bijna 63GB vrije ruimte, voor een totale capaciteit van 238GB.
De "totale capaciteit" zetten ze dus hoger dan de eigenlijke capaciteit, omdat ze verwachten veel te kunnen comprimeren. Als dit niet het geval is zal je 1GB niet comprimeerbare data opeens 2GB van je "vrije ruimte" afhalen. Of van de "totale capaciteit", maar dat denk ik niet. Dan zou de capaciteit van je harde schijf steeds variëren ;)

[Reactie gewijzigd door job_h op 16 augustus 2013 17:46]

Misschien was de 175GB aan data gecomprimeerd tot 57GB wat de opgegeven vrije ruimte wel 1:1 maakt.
Dat probeerde ik in m'n laatste twee zinnen te zeggen ;)

Dat leek me echter onwaarschijnlijk omdat dan de "totale capaciteit" steeds zou variëren. Ik kan me voorstellen dat het besturingssysteem raar zou reageren als een harde schijf steeds van grootte veranderd, maar misschien gaat dat ook wel prima.

[Reactie gewijzigd door job_h op 18 augustus 2013 13:06]

Ik huiver nu al voor de supportvragen: "waar is de overige GB dan gebleven?". Je ziet het nu al bij OS X waarbij Time Machine lokale backups maakt. Het is 1 van de meest gestelde vragen en alleen maar omdat een deel van het OS de ingenomen ruimte van de Time Machine backups simpelweg niet meerekent en het andere deel weer wel.

Het maakt management wel vrij lastig. Op storage gebied is het vaak zo dat men een bepaalde inschatting maakt voor bijv. de nabije toekomst of die over een paar jaar. Met dit nieuwe systeem is dat moeilijk omdat het zo veranderlijk is. Dit soort ssd's zou je dan ook eerder op gebied van caching in gaan zetten omdat dit daar wat minder van belang is. Daarom zal dit op moment ook wel specifiek voor het bedrijfsleven zijn en niet voor de consument.
Het is alleen veranderlijk als je continu verschillende data wegschrijft.
De gemiddelde database is zeer goed te comprimeren, het gemiddelde videobestand niet.
Dit werkt niet, zoals ook al met andere voorbeelden aangegeven is: stel ik schrijf eerst een tekstbestand met alleen spaties van 200GB weg; dat kan want comprimeert prima. Dan geeft ie nog zeg (krap gerekend) 119GB vrije ruimte aan. Dan schrijf ik daar een incomprimeerbaar bestand heen van 118GB en geeft de schijf 1GB vrije ruimte.

Nu overschrijf ik m'n tekstbestand met 200GB incomprimeerbare data. Dit zou onder normale omstandigheden moeten kunnen en nooit een fout geven, want ik gebruik geen nieuwe "vrije" ruimte. Echter dit gaat niet fysiek passen, want deze data neemt fysiek, samen met aanwezige data meer dan 120GB in beslag.

Hoe gaat de schijf/driver dit afhandelen??
De schijf en de driver roepen gewoon dat ze geen ruimte hebben.
Het OS (en potentieel de gebruiker) moet het uiteindelijk zelf oplossen.
Dit is bijvoorbeeld prima voor bulk storage. Daar wordt vaak een gedistribueerd filesystem gebruikt dat robuust om kan gaan met write fails.
Die ruimte is niet 1:1 vrij. Het is een schatting van wat ze denken dat ze kunnen comprimeren. Zo werken tenminste compressie programma's die ik ken,
Op dag 1 geeft hij dus aan 120GB, vervolgens zet je er 50 GB oncomprimeerbare data op (.zip files) en hij geeft nog maar 45 GB aan.
moet je maar even een textbestandje aanmaken met alleen maar spaties.
kun je doormiddel van VMware doen, gewoon een 900Peta byte schijf aanmaken,
onder compressive opslaan op je schijf geloof ik.

bij eigenschappen op je host zul je dan zien, bestandgroote 900PB, groote op schijf 1KB

zou je die dus op die schijf van sandforce opslaan, dan geeft hij een capaciteit aan van 900PB

ik zal het binnekort nog eens uit gaan proberen.

het is een x aantal jaar geleden toen ik een keer een ebstand gemaakt had van een paar PetaByte en dit gecompimeerd naar 1kb kreeg.
en voor de mensen die het toen niet geloofte stuurde ik het via MSN, en wat dan zo leuk was, over msn ging het ongecomprimeerd.
Dat is gewoon een zip-bomb, werd al gebruikt ten tijde van BBS.
moet je maar even een textbestandje aanmaken met alleen maar spaties.
kun je doormiddel van VMware doen, gewoon een 900Peta byte schijf aanmaken,
onder compressive opslaan op je schijf geloof ik.

bij eigenschappen op je host zul je dan zien, bestandgroote 900PB, groote op schijf 1KB
Dat heet een sparse file. Enkel de ruimte waar daadwerkelijk data in het bestand staat wordt weggeschreven naar het filesystem.
Sparse zou je kunnen zien als een soort compressie, maar wat neelespn bedoelt is dat, zou je een 'compressie' bestand op disk niveau verplaatsen, zit je toch weer aan de volledige grootte.
Totaal OffTopic,
maar ik kan hier niets uit maken:
maar wat neelespn bedoelt is dat,
"neelespn" = ?? 8)7 :?

[Reactie gewijzigd door HoeZoWie op 18 augustus 2013 12:47]

Volgens mij wordt er voornamelijk een vorm van data-deduplicatie toegepast als compressie-methode. Er wordt voor wat dat betreft weinig data ingepakt of uitgepakt; de data wordt enkel 'slim' weggeschreven. Het houdt tevens in dat de beschikbare ruimte ook altijd daadwerkelijk beschikbaar is en er uiteindelijk zelfs meer data naar kan worden weggeschreven.
En ik neem aan LSI meerdere vormen van compressie tegelijk toepast.

[Reactie gewijzigd door Ché Mig op 16 augustus 2013 18:48]

Ik denk niet dat ze data de-duplicatie gebruiken anders hadden ze nooit geroepen dat ze tot 2/3 aan ruimte kunnen winnen.
Bij data de-duplicatie kan het knap lastig voorspellen zijn wat de uiteindelijke compressiefactor wordt. Afhankelijk van de data kan de compressie enorm veel hoger worden dan wat ze aangeven.
En de-duplicatie maakt opslaan ook erg traag. Je zult eerst flink wat cpu cycles moeten verbruiken voordat je er achter bent of een stukje data uniek is of niet. En dat moet je voor elk stukje data die je wilt opslaan doen.
Bij het lezen moet je dan voor elk blokje data een boomstructuur doorzoeken om de index van de data te vinden.
Lijkt me op zn minst een ingewikkelde manier van werken..
Nee hoor, dat valt allemaal best mee. Daar hebben we nou eenmaal computers voor |:(
Precies de spijker naast zijn kop ;)

Puur softwarematig (Server 2012 R2) levert het al ongeveer 70% winst aan ruimte in ons virtual lab met VMs. Het is niet meer dan logisch om dat ook hardwarematig te gaan toepassen. Alleen de foutcontrole lijkt wat meer kritiek, maar zelfs dat is slechts virtueel.

EDIT: 2/3 winst op ruimte blijkt dus relatief eenvoudig bereikbaar. Het gaat om block-deduplicatie en niet om file-deduplicatie oid.

Daarnaast hoeft helemaal niemand niet te voorspellen wat de uiteindelijke compressiefactor wordt. De vrije ruimte is immers altijd volledig beschikbaar en je hebt de mogelijkheid om er uiteindelijk zelfs meer data naar toe te schrijven.
Je moet alleen niet proberen om 200GB data in 1 keer naar een 120GB SSD te schrijven, want het OS zal natuurlijk direct aangeven dat dat niet gaat lukken. De volledige data zal worden gekopieerd en vervolgens zal de SSD enigszins 'lazy' gaan uitzoeken welke duplicates er zijn en welke er dus verwijderd kunnen worden.

[Reactie gewijzigd door Ché Mig op 17 augustus 2013 21:14]

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013