Buffalo brengt DriveStation met 1GB dram-cache in Nederland uit

De firma Buffalo heeft een externe harde schijf van 2TB en 3TB aangekondigd die is voorzien van een 1GB dram-cache. Door de extra buffer zouden de lees- en schrijfprestaties volgens de fabrikant met ruim een factor 2 toenemen.

De HD-GDU3, die in de Drivestation-serie vallen, zijn leverbaar met 2TB of 3TB opslagcapaciteit en beschikken over een usb 3.0-interface. Door de vrij omvangrijke buffer van 1GB dram moeten de lees- en schrijfsnelheden flink toenemen. Buffalo claimt dat het wegschrijven van data snelheden tot 400MB/s te behalen zijn. Bij het lezen noemt het bedrijf doorvoersnelheden tot 300MB/s.

Volgens Buffalo zijn de twee Drivestation-modellen vooral geschikt voor gebruikers die veel met mediabestanden werken, zoals videoeditors of fotografen. De 2TB-versie heeft een adviesprijs gekregen van 169 euro, terwijl de 3TB-editie een prijskaartje van 219 euro heeft.

Reacties (37)

[the-dark-force]

buffalo heeft me een keer een linkstation weten te verkopen.
1gb/s netwerk verbinding enz enz... later kom ik erachter dat er nog geen film vanaf te streamen valt.
contact opgenomen: "ja er zitten beperkingen op dankzij de trage cpu..."

usb poort met een doorvoersnelheid van 50kb/s ondanks dat er een bloedsnelle ext. hdd. aanhangt

later bleek ook nog eens dat ondanks dat er xfs gepartitioneerd werd; waren de schijfen niet te benaderen wanneer ze niet in de nas zelf zaten (backtrack, ubuntu, mint & win 7 getest)
en dat de schijfen alleen vervangen konden worden na een lastige procedure die vorige pechvogels zelf hadden moeten uitzoeken omdat buffalo niet om klanten geeft.

ik raad dan ook iedereen aan om gewoon voor een fatsoenlijke hardware leverancier te kiezen om jezelf zo een hele boel koppijn te besparen, zelf een nas in elkaar te zetten of een oud systeem als nas te configureren.

[FreshMaker]

Daarom blijf ik vrolijk bij Synology, of Qnap ( volgens de ervaringen vergelijkbaar )

Geen gedoe met rare hardware, en zelfs de 'j' versie kan fatsoenlijk streamen over het netwerk ( SMB / NFS )
Je loopt alleen tegen beperkingen op, als je het apparaat "meer" gaat belasten, door de mooie package's die hier en daar aangeboden worden

[Z-Dragon]

Hoe groter zo'n schrijfcache, hoe langer het kan duren voordat "weggeschreven" data ook daadwerkelijk op de schijf staat, en je die bij (stroom)uitval niet kwijt bent. De dataveiligheid komt het dus bepaald niet ten goede.

[robertwebbe]

Tja, zo kun je alle ontwikkelingen wel neerhalen. Ieder voordeel komt nu eenmaal met een nadeel. Maar ik zie meer voordelen dan nadelen hier.

[kiang]

Niet echt hoor. Een grote cache in een HDD is echt niet zo nuttig.

Waar zijn HDDs het slechtst in? Kleine random read en write snelheden.

Worden die met deze cache opgelost? De leessnelheid alvast helemaal niet: enkel wanneer data reeds in de cache zit wordt deze HDD sneller. En wanneer zit data in de cache? Als die niet lang geleden reeds benaderd is en daarom nog in de cache zit, of als de data met pre-fetching preventief in de cache is geplaatst, maar efficiënte prefetching is onmogelijk bij random leesoperatie: dat werkt dus enkel bij sequentieel lezen.

Schrijven is iets anders: dat wordt met een DRAM cache inderdaad een stuk sneller: bestanden worden in de cache bijgehouden tot ze naar de schijf kunnen worden weggeschreven. Dat is inderdaad een heel stuk sneller (tot de cache vol zit, maar 1GB is plenty als je over random writes praat). het nadeel daarvan wordt echter wel aangehaald in de eerste post: het is onveilig bij stroomuitval. Een ingebouwde kleine batterij die het minstens 1 minuut uithoudt zou daarom een mooie toevoeging zijn aan deze HDD.

Dit persbericht en de heil van een DRAM cache moeten dus echt wel met een korrel zou genomen worden. Jouw commentaar suggereert dat we hier onnodig op zoek gaan naar kleine nadelen en die onnodig uitvergroten, maar dat is niet waar: deze DRAM is namelijk helemaal geen perfecte oplossing.

[ACM]

Elk modern OS zal dat soort dingen ook al proberen met DRAM: schrijfhandelingen bundelen om ze efficienter weg te schrijven, read-aheads doen om zo alvast wat winst te boeken op vervolgreads, veelgelezen data-blocks in RAM bijhouden.

Dat DRAM in zo'n externe disk voegt wellicht nog wel wat toe doordat het wat aggressiever ermee omgaat... Maar dat zou je ook in je OS kunnen tunen (het is in Linux iig vrij makkelijk te tunen, in windows is het vast ook een kwestie van de juiste parameters kennen).

Al met al is het dus maar de vraag hoeveel het echt toevoegt. Als ze er ook een backup-stroomvoorziening bij hebben zodat de disk zijn writes altijd kan garanderen, dan wordt het pas echt interessant. Want dan kunnen 'sync'-operaties ook allemaal overgeslagen worden, waardoor je bepaalde schrijfhandelingen aanzienlijk kan versnellen. Dit is tevens een van de belangrijkere winsten bij (dure) raid-controllers met hun ingebouwde caches (en dan met een BBU of nvram).

Lang verhaal kort: het is maar de vraag of die DRAM-cache in die externe disk echt wat toevoegt tov je OS-cache en de cache die er in de hard disk al ingebouwd zit.

[Verwijderd]

Random writes bundelen? Dat doen alleen CoW-filesystems zoals ZFS voor zover ik weet. Als we praten over Windows dan is er echt niet veel optimalisatie. Read-ahead is ook niet van toepassing op random reads. En read-ahead voor sequential read werkt al prima met een 32MB DRAM chip die in elke moderne hardeschijf terug te vinden is. Dat is ook nodig, want anders kan een hardeschijf enkel tegen 8MB/s lezen ipv 150MB/s (60 IOps * 128KiB). Read-ahead is dus vitaal voor het bereiken van hoge leessnelheden, net als write buffering dat is voor het bereiken van hoge schrijfsnelheden.

De DRAM 'cache' in dit product lijkt mij erg rudimentair. Zo wordt het verwerken van mediabestanden als voordeel genoemd. Dit doet vermoeden dat de DRAM enkel gebruikt wordt als last-access-cache en als write-buffer. Dit betekent dat de eerste 1GB die geschreven wordt, tegen maximale snelheid gaat. De cachefunctionaliteit hiervan valt te verwaarlozen, omdat je enkel in synthetische benchmarks data terugleest die je net hebt geschreven. Als een applicatie dat al doet, dan wordt dit afgehandeld door de filecache in je systeem RAM.

Gevaarlijk is een grote DRAM buffer in dit geval niet, omdat zeer waarschijnlijk de FLUSH requests worden geëerbiedigd. Dit is noodzakelijk om de integriteit van het bestandssysteem te garanderen bij onverwacht stroomverlies. Moderne hardware RAID controllers hebben een beveiligde DRAM buffer en die kunnen zonder veel risico dergelijke FLUSH requests negeren - waar je ook op doelde in je bericht. In dit geval lijkt daar geen sprake van te zijn.

Dit betekent ook gelijk dat het versnellen van random writes vrijwel afwezig zal zijn, omdat in de praktijk random writes vergezeld zullen worden door sync writes en dat triggered dus een situatie waarbij de DRAM geleegd moet worden voordat de volgende schrijfactie mag worden afgehandeld. Kortom, alleen sequential writes zullen worden versneld.

Een intelligente cachestrategie zou zijn om enkel random reads te cachen, ongeveer zoals een NAND cache ook gebruikt wordt in hybride hardeschijven of bij Intel SRT caching. Dan zou één van de grootste nadelen van hardeschijven verzacht kunnen worden. Maar door het vluchtige DRAM zal dit effect beperkt blijven omdat na elke power cycle de cache weg is, en aangenomen dat de klant eens per dag een power cycle doet zal de systeem RAM een veel grotere cache vormen en daarmee de cache in het opslagapparaat overbodig maken.

Concluderend, leuk voor de marketing dit en voor mensen met grote mediabestanden heeft het wellicht nog wel enig nut. Maar de grote potentie van caching vereist meer intelligentie om effectief te zijn. Een goed voorbeeld van intelligente caching kunnen we vinden in ZFS, die met zijn adaptive replacement cache zowel last-access als most-frequently-accessed data cached. Overigens mogen we in dit verband niet spreken over een cache. Het gaat hier hoofdzakelijk om een buffer. Een buffer wordt veelal incorrect als cache aangeduid, omdat dit eenmaal een bekendere term is. Een buffer die tevens als cache dient, wordt meestal buffercache genoemd.

[ACM]

Ik doelde eigenlijk op o.a. deze twee technieken:
- Write scheduling waarmee opeenvolgende writes - voor zover dat 'mag' - in een andere volgorde worden uitgeschreven ze gunstiger op het draai-gedrag van de disk af te stemmen. Voor zover ik weet doet in ieder geval Linux hier aan.
- Logfiles in moderne filesystems/OS-en: Lineair uitschrijven van nieuwe data naar de logfile en dat te zijner tijd op een gunstig moment op een handige volgorde uitschrijven. Eventuele re-writes die binnenkomen in een korte tijdspanne worden dan ook gebundeld tot een uiteindelijke write.

ZFS is daar helemaal koning in inderdaad

[cdwave]

De linux kernels doen al heel lang de IO "sorteren" vanuit de cache. Dat staat nog los van het gebruikte filesysteem, dus zelfs FAT of ext2 profiteert hiervan.

Als je vanuit userspace de sectoren beschrijft als 1, 10, 2, 11, 3 zal de linux kernel ze waarschijnlijk in de volgorde 1, 2, 3, 10, 11 naar de hardware sturen (als er ruimte in de cache was enzo).

In de kernel wordt dit een "elevator" genoemd.

De cache in een disk drive is altijd al bedoeld geweest om de bussen efficienter te kunnen gebruiken. De transactie vanuit memory kan veel sneller verlopen dan de data van de fysieke drager wordt gelezen. Door eerst de data in een buffer te lezen en dan pas een seintje te geven aan de controller dat er data beschikbaar is, hoeft de disk de databus niet zo lang in gebruik te houden, en kunnen andere devices (met liefst ook zo'n buffer) hem beter delen. Een disk die fysiek 100 MB/s kan transporteren zal op een SATA-600 connectie maar 1/6 van de tijd actief hoeven zijn om zijn maximale throughput te halen.

Groter maken van zo'n on-disk cache heeft nauwelijks effect, als hij eenmaal over de drempel heen is van de IO voegt het helemaal niks meer toe aan de OS disk cache. Sterker nog, gewoon het systeemgeheugen met 1GB uitbreiden zal meer effect hebben, omdat de toegang tot dat geheugen veel sneller is dan via de bus naar het device toe, en omdat er dan niet dubbel gecachet wordt.

[Z-Dragon]

Het is maar om even aan te geven dat het allemaal niet zo geweldig is als het lijkt en de natuurlijke reactie "meer is beter" onjuist is. No free lunch.

[Reactie gewijzigd door Z-Dragon op 29 juli 2024 11:57]

[Verwijderd]

hangt af van de firmware: zo kan deze direct beginnen wegschrijven vanaf er data op de cache staat en deze dan verwijderen uit de cache. Niets in het artikel wijst erop dat de cache vol moet zijn voor deze naar de hhd geschreven wordt.

[EvilWhiteDragon]

Dat maakt niets uit voor wat hij hier zegt. Als je cache van 1 GB vol zit, dan duurt het nog zeg 1000/150=6 seconden voordat je cache helemaal leeg is. Alles wat tijdens die 6 seconden weggeschreven moet worden kan verloren gaan als de stroom uitvalt. Zonder battery backup unit of UPS is dit dus een best gevaarlijk, zeker voor een externe disk. Externe disks worden toch net even wat sneller "zomaar" afgekoppeld dan interne disks.

[Reactie gewijzigd door EvilWhiteDragon op 29 juli 2024 11:57]

[Ortep]

Dat maakt niets uit voor wat hij hier zegt. Als je cache van 1 GB vol zit, dan duurt het nog zeg 1000/150=6 seconden voordat je cache helemaal leeg is.

Dan ga je er van uit dat die cache alleen maar schrijft als hij vol is. En dat je dan net vlak voor hij vol is de stroom er af haalt. De praktijk is dat een cache zo snel mogelijk word weggeschreven. En dat gaat gemiddeld sneller dan losse schrijf acties op een schijf. Dan vliegt nl de kop heen en weer over de platters. En met een cache kan je optimaliseren door in een 'handig' patroon weg te schrijven.
Daar komt nog bij dat het natuurlijk ook een lees cache is en niet alleen een schrijf cache. Veel van de informatie komt er in terecht omdat het van de HD gelezen is en daarna veel sneller ter beschikking is als je het een tweede keer vraagt. Die informatie hoeft dus niet te worden weggeschreven, het stond op de schijf.

[Z-Dragon]

Hoe voller die cache komt te zitten, hoe beter hij wordt benut. Wat er niet van benut wordt, hadden ze beter weg kunnen laten. Als alle data toch direct weggeschreven zou worden naar de harde schijf, had die cache natuurlijk geen enkele snelheidsverbetering tot gevolg gehad. Voor lezen is het inderdaad wel prettig, mits een goed algoritme bepaalt wat in de cache blijft.

[Ortep]

Hoe voller die cache komt te zitten, hoe beter hij wordt benut. Wat er niet van benut wordt, hadden ze beter weg kunnen laten. Als alle data toch direct weggeschreven zou worden naar de harde schijf, had die cache natuurlijk geen enkele snelheidsverbetering tot gevolg gehad.

Een cache wordt niet 'geleegd' als hij wordt weggeschreven. Het blijft er in staan zodat je er wat aan hebt als je het weer wilt lezen. Waar de schrijfwinst in zit is het snel kunnen opvangen van 'bursts' van data. De disk kan minder snel opvangen dan de cache en die loopt vol. De disk blijft zo snel mogelijk wegschrijven. Als er dan even 1-2 seconden geen data uit je PC komt, dan gaat de disk gewoon door met wegschrijven van dan de cached data. Als die cache er niet tussen zat, dan moest het hele systeem wachten tot de schijf klaar was. En nu dus niet. En zoals ik al schreef: Het wegschrijven gaat efficiënter als je grote hoeveelheden weg moet schrijven dan steeds 1 sector. Het enige wat het wegschrijven doet is er voor zorgen dat de inhoud van de cache gelijk is aan die van de disk.

Natuurlijk bepaalt een goed algoritme wel wat je beter kan behouden en wat niet als hij vol raakt. Maar zolang hij niet vol zit blijft hij gewoon alles bewaren.

[Reactie gewijzigd door Ortep op 29 juli 2024 11:57]

[EvilWhiteDragon]

Ik weet zo niet wat gangbaar is voor HHD's van die grootte, maar 150MB/s sustained write (waar je het ook over hebt met geoptimaiseerd schrijven) lijkt mij een aardige orde van grootte. Ik haal zelf iets van 120-140MB/s sustained write op een 3TB disk.

Ik neem aan dat je 1 GB cache helemaal vol is geraakt. Iets wat met 400 MB/s in 2,5 seconde te doen is. In die 2,5 seconde kan je inderdaad ook met zeg 150 MB/s data wegschrijven. Dan krijg je de volgende vergelijking: 1000=x*(400-150), waarbij je na 4 seconden je cache vol hebt, als deze met 150MB/s data wegschrijft en met 400 MB/s data opslaat. Op dat moment zal het dus nog 6 seconden duren voordat je cache compleet leeg is, als je dan stopt met het schrijven van data naar je cache. In die 6 seconden is stroomuitval dus nog steeds een gevaar voor je data.

[Verwijderd]

Ik hoop dat er daarom ook eens een fabrikant (Synology, Buffalo etc.) komt die een NAS en/of gewone externe harddisk, voorziet van een backup battery.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 11:57]

[masteriiz]

In feite heb je genoeg aan een capacitator die je apparaat lang genoeg in de lucht houdt om de cache weg te schrijven.

[kiang]

Om nog maar te zwijgen over het feit dat de schrijfsnelheid helemaal instort als je kleine bestanden gebruikt: dan is de snelheid soms nog maar 0.5 MBps!

In dat geval is het frame van onveiligheid voor stroomuitval dus enorm veel groter.

[watercoolertje]

Heeft volgens mij een stuk meer invloed bij lezen dan bij schrijven gezien er bij een normale hdd juist niet extreem random wordt geschreven... en bij lezen is stroomuitval weer niet erg.

[cdwave]

Het OS (bijvoorbeeld Linux) onderhandelt over write-caching met de drive. Zo weet het OS precies wanneer een bepaald deel van de journal op de fysieke drager is weggeschreven. Vanuit userspace kun je aan de kernel vragen om data naar de fysieke drager over te brengen, en krijg je notificatie wanneer dit afgerond is. Zo kan een database bijvoorbeeld robuust worden gemaakt tegen onverwachte power-outs, en toch profiteren van de performance van een write-back cache.

Na power uitval wordt het journal bekeken, en het filesysteem in een consistente status gebracht. Dat wil dus zeggen dat er mogelijk data verloren is gegaan, maar het zal niet leiden tot corrupte filesystemen, en ook user applicaties kunnen achterhalen welke data nog betrouwbaar gecommit is.

[Ortep]

In de vorige eeuw waren er al cached raidcontrolers die een back-up accu hadden. Die konden 72 uur de zaak vasthouden. Bij een stroomstoring waarbij onze server er in één keer uitknalde was van alles nog niet weggeschreven. Toen er weer spanning was startte de hele zaak op en direct na de bios schermen kwam er een scherm van de controller dat hij de raid ging checken en toen een mededeling er een discrepantie was tussen cache en disk. Hij stond een minuut of 5 te pruttelen en daarna was alles weer in orde.
Ik denk dat we een jaar of 15-20 na die tijd de zaak nog wel beter kunnen regelen. Een cache hoeft dus echt geen nadeel te zijn, als hij maar goed is uitgevoerd.

Daar komt nog bij dat het wegschrijven veel sneller gaat als je van te voren weet wat je moet doen. En dat weet je als je een cache gebruikt.

[Reactie gewijzigd door Ortep op 29 juli 2024 11:57]

[Z-Dragon]

Een dergelijke batterij wordt niks over vermeld en het zou me verbazen als die in dit consumentenproduct inderdaad aanwezig zou zijn.

[analog_]

It's too easy not too, zou ik denken als techniek alles dicteerde.

[Verwijderd]

Het merendeel van de mensen die een dergelijke schijf (in deze prijsklasse) bij/via mij hebben bemachtigd heb ik direct juist ook om die reden geadviseerd om direct een UPS van APC aan te schaffen onder het mom "zekerheid voor alles".

[Reactie gewijzigd door Verwijderd op 29 juli 2024 11:57]

[joo5ty]

Ja. .. de laatste tijd is de stroom al vaak uitgevallen... en toen moest ik flink balen dat ik mijn foto's opnieuw moest kopiëren!

[masteriiz]

Dit doet me ook denken aan thuisgebruikers die zitten te klooien met RAID 5, UPS, mirroring et cetera. Serieus, wat doe je thuis dat dit verantwoord? Voor thuisgebruik lijkt mij af ten toe een backup draaien voldoende. Risico is normaal gesproken PD*LGD, of kans maal schade. Beiden lijken mij hier inderdaad nihil.

Systemen waarbij dit wel uitmaakt zullen geen WD drivestation gebruiken.

[cdwave]

Sterker nog - meestal gaan de foto's verloren door stommiteiten die begaan worden tussen stoel en toetsenbord. De mirror voert die stommiteit razendsnel dubbel uit, en weg data.

Een doodgewone backup heeft dat probleem niet. En als je het een beetje handig opzet, kun je ook stommiteiten van een paar dagen geleden oplossen.

[Verwijderd]

Als je data zo belangrijk is dat je zorgen maakt om data verlies dan gebruik je bij voorbaat al een UPS, dus een redelijk zinloze discussie.

OT: Een mooi en goedkoop systeem om een snelle NAS te maken voor je thuis gebruik ( films/ muziek etc. )

[croxz]

Het heeft alleen een USB aansluiting om direct aan de PC te hangen, als NAS kan het dus niet ingezet worden.

[masteriiz]

Beetje router heeft tegenwoordig USB aansluitingen. USB3 moet je iets beter naar zoeken, en lijkt me met deze snelheden onontkoombaar, maar daar zijn er al vijf van
http://tweakers.net/categ...DRZYk5SlbRSsZmlhZKsbW1tQA

[Madrox]

Interessesant. Nu nog zoiets met een Raid interface.

[Nas T]

Door de extra buffer zouden de lees- en schrijfprestaties volgens de fabrikant met ruim een factor 2 toenemen.

Goh, verrassend.

Buffalo claimt dat het wegschrijven van data snelheden tot 400MB/s te behalen zijn.

[obviousquestion]Onder alle omstandigheden?[/obviousquestion]
[honestanswer]Nee.[/honestanswer]

Ik wil het niet accepteren dat alle fabrikanten dat doen. Dat weiger ik, uit principe.
Intel reclameert vaak wel met reële cijfers, door percentuele prestatietoenames te noemen ten opzichte van vorige producten die wèl op de realiteit slaan.
Er is in dit geval geen rakettechnologie voor nodig om reële cijfers te geven, dus NEE, dan accepteer ik het niet dat een fabrikant volslagen onduidige cijfer roept als zijnde "prestaties". Het geeft een stukje van de werkelijkheid weer, niet de relevante hele werkelijkheid.

[unglaublich]

En waarom vind jij dat een reactie op de first post? Zo werkt het natuurlijk niet.

Overigens is er geen één op één relatie tussen de lees- schijf prestaties en de buffergrootte dus dat kan best verrassend zijn.

Je laatste punt is natuurlijk waar, marketing is de meest vreselijke tak van een commercieel bedrijf. Ze gooien een rookgordijn op voor het werkelijke product om onwetende consumenten te misleiden. Walgelijke manier van je product verkopen. Wat dat betreft begrijpt Intel het misschien beter maar zij hebben ook klanten die terugkomen omdat het product heeft bevallen. In tegenstelling tot een gebruiker van dit drivestation dat er achter komt dat er helemaal geen 400MB/s gehaald wordt .

[Verwijderd]

videoeditors of fotografen...

Ik denk dat die hier juist weinig voordeel mee hebben?
Als je gaat bewerken haal je het van de schijf af met je programma, en wordt het dus in memory/de cache van je computer geladen. Het is 1 keer laden, bijna nooit in de cache van de harde schijf.
Je catalog van lightroom staat op de lokale schijf, dus ook daar telt de externe schijf niet.
Tenzij hij gebruikt wordt als read-ahead, dan kan het significant schelen. Maar dat haal ik niet uit het artikel?

[Sfynx]

Ik zie niet echt de bijzonderheid van 1 GB RAM cache in een opslagserver, elk systeem met ZFS en een beetje RAM doet dat ook.

edit: my bad, ik dacht even dat het hier om een NAS ging.

[Reactie gewijzigd door Sfynx op 29 juli 2024 11:57]

[JayJay]

Klinkt als ... marketing als dit daadwerkelijk zo'n wereld van verschil had moeten zijn waren ze er eerder mee gekomen (toen usb3.0 net uitkwam)

Duur maar snel SSD als externe SSD.