Nieuwe generatie SandForce-ssd's krijgt extra virtuele capaciteit

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.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (71)

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.

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.

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.

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.

Het bronartikel geeft aan dat het geenzins bedoeld is voor consumenten, maar voor cloud servers en datacenters (wat ze daar dan ook mee mogen bedoelen). Ik denk dat het Windows screenshotje alleen als demonstratie is, maar dat het niet goed zal werken in Windows. Inderdaad om al de genoemde problemen met partities die niet zomaar meeschalen en andere problemen.

Een zoekopdracht op Google levert vervolgens nog wat informatie op dat het ook bedoeld is voor specifieke taken. In de PDF die ik kon vinden hadden ze het specifiek over databases. Daar is vaak aanzienlijke compressie te behalen. Als je zo'n disk uitsluitend gebruikt voor database gebruik dan heb je een redelijk stabiel compressie percentage. Als je 1e 5 miljoen rows 25% kleiner kunnen worden is de kans groot dat je 2e 5 miljoen rows eveneens 25% kleiner kunnen worden. Het risico van verkeerd ingeschatte capaciteit is daardoor denk ik relatief klein. Er zal ook wel een zekere veiligheidsmarge in zitten.

Uit http://www.lsi.com/techno...ite-virtual-capacity.aspx haal ik dat de controller 1x een capaciteit schatting doet (capacity projection), en dat verder middels SMART attributen de beschikbare data kan worden aangepast. Er zullen dus vermoeddelijk aparte drivers nodig zijn en aangepaste filesystems om dit goed te kunnen benutten. Vandaar ook dat het niet geschikt wordt geacht voor consumenten.

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)

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?

Je moet er niet te jong voor zijn... maar meer mensen die aan 'Stacker' dachten uit het oude DOS-tijdperk? Toen een 20MB hardeschijf nog ENORM was en je er een 30 tot 40MB schijf van kon maken met Stacker?

Dat was ook mijn eerste gedachte: Stacker. Ik heb de opkomst van stacker meegemaakt, en was er eerst heel enhousiast over. Veel bestanden konden aanzienlijk gecomprimeerd worden, en soms werd het systeem zelfs iets sneller met inlezen. De schijven waren nog vrij langzaam toen.
Je moest wel oppassen met diskcompressie programma's. Sommigen werkten zo low-level dat ze nog onder de stacker driver werkten.

Langzaam aan werd ik iets minder enthousiast. Een verminkt bestand was vaak compleet onleesbaar, en een 250 kB bestand van floppy kon je ruimte op de harde schijf met soms wel 500 kB doen afnemen.
Bovendien werd het systeem toch merkbaar trager met veel lees/schrijf acties, b.v. tijdens compileren.

En ik had een collega (geen grap) die Stacker én DoubleSpace tegelijk gebruikte. Hij was er van overtuigd dat ie 4x zo veel data op zijn fysiek 80MB grote WD Caviar kon zetten.
Omdat je niet zomaar 300MB bij elkaar kreeg had ie er ook (op performance na) geen last van...

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.

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.

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]

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

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]

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.

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.

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" = ??

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

Dat is gewoon een zip-bomb, werd al gebruikt ten tijde van BBS.