'Samsung en Microsoft werken aan betere ssd-ondersteuning'

Hardwarefabrikant Samsung gaat samen met softwaremaker Microsoft werken aan betere ondersteuning van solid state disks in het Windows-besturingssysteem. Details maakten beide bedrijven nog niet bekend.

Sandisk, eveneens fabrikant van onder meer ssd's, gaf vorige maand te kennen drie solid state disks niet uit te zullen brengen. Het bedrijf gaf als reden voor het uitstel tekortkomingen van Vista: het nieuwste besturingssysteem van Microsoft zou niet goed met ssd's met grote capaciteit om weten te gaan. De flashfabrikant zou van plan zijn zelfstandig een oplossing te vinden en zo beter presterende ssd's te ontwikkelen. Samsung zou echter een alternatieve weg bewandelen en samen met Microsoft naar een oplossing zoeken.

Volgens Samsung is optimalisatie van de manier waarop Windows met ssd's als opslagmedium omgaat nodig. Dat zou, volgens een analist van Forward Insights, kunnen betekenen dat er gewerkt wordt om Windows te leren met de grotere sectors van ssd's om te gaan. De ssd-sectors zijn 4KB, terwijl die van harde schijven in het algemeen 512 bytes groot zijn. Optimalisaties zouden tot een betere efficiëntie van dataverkeer van en naar de ssd's moeten leiden. Naast een betere compatibiliteit tussen ssd's en Windows zou Samsung ook het energieverbruik van zijn ssd's willen verminderen en de levensduur verlengen.

Windows zou niet het enige besturingssysteem zijn dat geoptimaliseerd wordt voor gebruik met ssd's: Samsung werkte al met Sun samen om betere ssd-ondersteuning in Suns zfs te realiseren. Dit bestandssysteem wordt onder meer in het besturingssysteem Solaris gebruikt. Sun denkt ssd's nog dit jaar in zijn opslagportfolio op te nemen. Beide bedrijven denken dat defragmentatie in ssd's mogelijk zal zijn, aangezien dat voor betere prestaties zou zorgen. De huidige ssd's worden niet gedefragmenteerd, omdat defragmenteren een zware wissel op de levensduur van ssd's zou trekken.

Reacties (44)

[Verwijderd]

Beide bedrijven denken dat defragmentatie in ssd's mogelijk zal zijn, aangezien dat voor betere prestaties zou zorgen.

Tot op heden ging ik er van uit (en ik heb het meerdere mensen horen zeggen) dat fragmentatie een non-issue was op SSD's, omdat er geen mechanische kop van de ene naar de andere kant bewogen hoeft te worden, dus ik was even verbaasd over deze opmerking.
Mazar blijkbaar zitten in SSD's optimalisaties om grote hoeveelheden aaneengesloten blokken in 1x uit te lezen, of zo...
ik vermoed dat fragmentatie wel veel minder impact op de performance zal hebben dan op conventionele schijven en ik vraag me af of je met defragmentatie echt veel verbetering gaat merken.
Er zijn wel bestandssystemen die zelf fragmentatie tegen gaan, maar dit soort logaritmen zijn denk ik niet eenvoudig om later alsnog toe te voegen in een bestaand filesysteem.

[Dutch2007]

feature toevoegen, daarna defragmenteren , voormij part IN de update verwerken dat dit moet gebeuren ;-)

[.oisyn]

Bestaande moderne filesystems gaan fragmentatie al zoveel mogelijk tegen. Je kan het echter nooit helemaal voorkomen. En natuurlijk is fragmentatie voor SSDs minder een issue dan bij HDDs, maar het is wel nog steeds een issue. Je hebt veel meer overhead naar de controller, en ook flash memory heeft access times waarbij sequentiele access sneller is dan random access.

maar dit soort logaritmen

Algoritmen. Een logaritme is een wiskundige functie: ^blog x = y <=> b^y = x

[Reactie gewijzigd door .oisyn op 27 juli 2024 02:16]

[Verwijderd]

Nog steeds is het niet duidelijk wat er zo slecht ondersteund zou zijn, en al helemaal niet waarom Vista daarin zo veel slechter zou zijn.... Die 512 bytes vs. 4KB sector size geldt immers voor alle Windows versies. (Eigenlijk alle OS-en)...

Zowiezo geloof ik dat sector grootte verhaaltje niet zo... NTFS werkt standaard met een 4 KB cluster grootte. Dat is dus precies hetzelfde als de SSD sector grootte. FAT werkte vroeger met nog veel grotere clusters... Ik zie niet in waarom Windows hier problemen zou veroorzaken.

[Fiander]

Zowiezo geloof ik dat sector grootte verhaaltje niet zo... NTFS werkt standaard met een 4 KB cluster grootte. Dat is dus precies hetzelfde als de SSD sector grootte. FAT werkte vroeger met nog veel grotere clusters... Ik zie niet in waarom Windows hier problemen zou veroorzaken.

Even voor jou informatie, een cluster is zoals het besturingssysteem de disk ziet.
Een sector is zoals de disk de data ziet.

Een cluster is dus opgedeelt uit meerdere sectors.
Het probleem zit em er in dat in dit geval de disk de data in blokken van 4K ziet, en ook wil versturen, en dat het OS ( op dit moment is het niet vista gebonden ) het verwacht in stukken van 512B.

Door nu de driver aan te passen voor het disk IO systeem, zou het OS de data wel in blokken van 4K moeten kunnen ontvangen.

En persoonlijk hoop ik dat de HDD fabrikanten dit ook oppakken, en ook overstappen op 4K sectors.

edit : Ik lees net dat ze daar al druk mee bezig zijn .
http://www.extremetech.com/article2/0,2845,1902074,00.asp

[Reactie gewijzigd door Fiander op 27 juli 2024 02:16]

[Verwijderd]

Zowiezo geloof ik dat sector grootte verhaaltje niet zo...

ok best
als we daar niet even over hybris spreken
dit is een conclusie van 2 gigantische bedrijven, maar toch zou hu samenwerking gebaseerd zijn op gebakken lucht. Overweeg misschien de mogelijkheid dat ze meer weten over de interne problemtiek dan jij?

[Reactie gewijzigd door Verwijderd op 27 juli 2024 02:16]

[Ge Someone]

Het gaat er ook om de juiste sector bounderies te gebruiken, zodat je niet een 4k cluster maakt waarvan 2k bij de ene SSD sector hoort en 2k bij de volgende.

[Blokker_1999]

Beide bedrijven denken dat defragmentatie in ssd's mogelijk zal zijn, aangezien dat voor betere prestaties zou zorgen. De huidige ssd's worden niet gedefragmenteerd, omdat defragmenteren een zware wissel op de levensduur van ssd's zou trekken.

Maar word het dan eens geen tijd dat men de bestandssystemen aanpast zodat fragmentatie zoveel mogelijk voorkomen word?

[Verwijderd]

Met HPFS (OS/2) hadden we al een bestandssysteem dat vrijwel niet fragmenteerd. Is me niet duidelijk waarom die gebruikte technologie daarvan niet meer in NTFS is gebruikt. HPFS is immers door Microsoft geschreven, dus ik kan me niet voorstellen dat er licentie problemen zouden zijn.

[Rob Coops]

Ik denk dat het OS/2 systeem van IBM is en niet van Microsoft, als IBM zo iets koopt bij Microsoft dan hebben ze zeker weten ook de rechten gekocht, anders hadden ze het zelf wel ontwikkeld. Microsoft had anders immers OS/2 simpel kunnen blokkeren door flinke licentie gelden te vragen voor iedere instalatie iets wat ze nooit gedaan hebben.

Daarnaast denk ik dat HPFS toch ook zo z'n beperkingen had anders had Microsoft niet zo veel moeite gehad om een fatsoenlijk file systeem te bouwen dat geen fragmentatie problemen kent. Eigenlijk denk ik dat het een raar concept is een file systeem dat geen fragmentatie veroorzaakt dat is niet iets waar een file systeem iets over te zeggen heeft lijkt me. Uit eindelijk bied je de data aan de harddisk controller aan om weg te schrijven en hoe je file systeem dat ook doet de data wordt toch echt weg geschreven door de harddisk controller en die heeft maar een doel, die buffer moet zo snel mogenlijk leeg zodat de volgende data set weg geschreven kan worden.

[.oisyn]

Ik denk dat het OS/2 systeem van IBM is en niet van Microsoft

OS/2 was een collaboratie van IBM en Microsoft, maar is later voortgezet door IBM (vanaf OS/2 1.3) toen Windows 3.0 zo'n enorm succes werd en MS dus al hun aandacht daarop besteedde. HPFS zat al in OS/2 1.2 en is geschreven door Microsoft, en HPFS support zat ook in Windows NT (wat van origine eigenlijk als nieuwe OS/2 versie was bedoeld). Voor de snellere HPFS386 driver moest IBM weldegelijk royalties betalen aan MS.

Daarnaast zit fragmentatie weldegelijk in je filesystem. Je filesystem als geheel is namelijk gewoon een grote chunk data op je hdd, en waar iets staat opgeslagen in je filesystem bepaalt waar dat op je hdd terecht komt. Fragmentatie betekent dat files in stukjes kriskras in het filesystem (en dus ook op de HDD) staan opgeslagen. De HDD controller weet niets van files, en kan dus ook niets aan die fragmentatie doen.

Een van de kenmerken van HPFS is idd dat het minder fragmenteert. Maar geen enkel FS kan het voorkomen zonder actief te defragmenteren bij het verwijderen en aanmaken van file blokken, wat performance niet ten goede komt. Maar het kan wel een heuristiek gebruiken bij het toekennen van blokken zodat alle blokken van een file iig dicht bij elkaar staan (maar niet per se achter elkaar), of dat er ruimte achter files niet direct wordt gealloceerd zodat de file ruimte heeft om te groeien. En ook NTFS heeft dergelijke heuristieken, dus HPFS is niet zozeer nodig.

[Reactie gewijzigd door .oisyn op 27 juli 2024 02:16]

[Verwijderd]

Misschien een loze opmerking... maar stel... Ik zet een film van 300MB op mijn schijf daarna zet ik nog films erbij op totdat de schijf vol is... daarna gooi ik nummer 2 - 4 - 6 - 8 etc weg... oftewel... ik heb om de 300mb, 300mb vrij... (in een perfecte wereld ofc...) hoe wou zowel het filesystem als de hardeschijf het opvangen als ik dan in een keer een film van 25GB erop zou zetten? Lijkt mij onmogelijk om dan de bestanden ONGEFRAGMENTEERD weg te schrijven... immers de disk heeft om de 300MB, 300MB vrij... die worden daarna gewoon opgevuld met stukjes van die 25gb... 't zou GIGANTISCH veel snelheidsverlies betekenen als hij die 25gb film ongefragmenteerd zou wegschrijven want hij moet immers eerst elke film naast elkaar gaan zetten...

Oftewel... in het begin kan je redelijk ongefragmenteerd wegschrijven maar zodra je dingen gaat weggooien maak je "gaten" in je hardeschijf, en die worden altijd eerst opgevuld (als het goed is).

Hetzelfde geldt ook voor de "Noobs" die nu gaan roepen dat ext3/reiserfs/hfs etc. etc. nooit kunnen fragmenteren... er zijn zelfs benches die dat meten op die FS's. Alleen omdat er misschien geen "standaard" defragmentatie programma wordt meegeleverd betekend het niet dat het FS niet framenteerd..


edit... ik bedenk me net een leuke analogie (of hoe heet dat )

Stel ik zet 100 cdhoesjes naastelkaar zodat mijn kast vol zit, daar haal ik iedere even cdhoes tussenuit (zonder dat de andere hoesjes omvallen ofc.) Nu koop ik een Dubbelcd... die wil ik in mijn kast kwijt, wat natuurlijk wel past maar dan zou ik eerst al mijn schijfjes weer netjes tegenelkaar aan moeten zetten of ik haal de 2 cd's uit het hoesje en steek ze in een ander hoesje om ze ertussen ts kunnen steken...
de eerste mogelijkheid zou ik mijn dubbelcd gaan fragmenteren om het te laten passen...

in het eerste geval ben ik 10 minuten kwijt (fictief) in het andere geval 20 seconde want ik heb de cdhoesjes naast de kast liggen..

't Zelfde geldt voor een hardeschijf...

[Reactie gewijzigd door Verwijderd op 27 juli 2024 02:16]

[DLGandalf]

OS/2 werd door IBM EN MS gemaakt. ik denk dat ze alle rechten delen.

[Verwijderd]

Microsoft is reeds bezig aan exFAT. Dus ofwel maken ze een afgeleide voor de desktop of ze gaan exFAT verder ontwikkelen en op de desktop duwen.
Snap niet waarom zoiets niet in het artikel stond.

[TommyCP]

exFAT is bedoeld als opvolger voor FAT32, speciaal voor removable flash media en apparaten met weinig rekenkracht. Door het simplisme van de structuur van exFAT wordt de hoeveelheid overhead in vergelijking met NTFS geminimaliseerd. Echter, hier staat tegenover dat exFAT door zijn simplisme veel minder features heeft dan NTFS (om er bv. één te noemen: geen ondersteuning voor file system permissions), wat het onaantrekkelijk maakt om het voor desktop PC's te gebruiken.

Een afgeleide van exFAT speciaal voor de desktop, die meer features kent en zo als vervanger voor NTFS kan fungeren, zal er denk ik niet komen, omdat dit haaks staat op het idee achter exFAT, namelijk om het simpel te houden. Daarnaast gok ik dat het tweaken van (het volwassen) NTFS minder werk is dan het uitbouwen van een gloednieuw bestandssysteem als exFAT.

[Reactie gewijzigd door TommyCP op 27 juli 2024 02:16]

[hiostu]

exFat zit al in Vista SP1. Aangezien dat al bestaat zal dit wel niet toereikend zijn, anders zou de samenwerking met Samsung niet opgezet zijn

http://en.wikipedia.org/wiki/ExFAT

[hellfire_ultd]

Maar word het dan eens geen tijd dat men de bestandssystemen aanpast zodat fragmentatie zoveel mogelijk voorkomen word?

Een quote van Wikipedia over een bestandssysteem van 7 jaar oud:

Modern Linux filesystem(s) keep fragmentation at a minimum by keeping all blocks in a file close together, even if they can't be stored in consecutive sectors. Some filesystems, like ext3, effectively allocate the free block that is nearest to other blocks in a file. Therefore it is not necessary to worry about fragmentation in a Linux system.

Microsoft's NTFS heeft vergelijkbare features:

The Master File Table (MFT) contains metadata about every file, directory, and metafile on an NTFS volume. It includes filenames, locations, size, and permissions. Its structure supports algorithms which minimize disk fragmentation.

[miw]

Een belangrijke eigenschap van SSD's is juist niet dat het vrijwel geen seek latency heeft, zodat het dus een stuk minder uitmaakt dat een bestand al dan niet in opeenvolgende geheugenlocaties is opgeslagen. Een file systeem defragmentatie laten tegengaan is veel belangrijker voor HDD's dan voor SSD's. Beetje vaag argument in deze context dus.

[P5ycho]

Dat is het niet. read seek times liggen in de tienden van milliseconden, maar random write seek times liggen veel hoger, tot wel 250ms bij sommige SSDs. Als je schijf gefragmenteerd is en een file dus over meerdere plaatsen op je SSD uitgestreken wordt is het dit degelijk van belang!

[Fiander]

???????????
Je loopt nu te beweren dat SDD's veel trager en veel hogere seektimes hebben dan HDD's ?

Een SDD heeft een toegangs tijd van 0.1 tot 0.7 ms.
en natuurlijk is het sneller om tegen een disk te zeggen : doe mij sector 1 tot 100
dan dat je moet zeggen : doe mij sector 1 tot 5, 11 tot 31, 45 tot 50, 32 tot 40 ...... enz

defragmenteren zal dus het opvragen gemakkelijker maken, met minder opdrachten,
en voor de disk zal het gemakkelijker worden, omdat het ipv veel kleine lees opdrachten, het een grote lees opdracht word.

edit : foutje

[Reactie gewijzigd door Fiander op 27 juli 2024 02:16]

[Verwijderd]

Beter lezen. Hij heeft het over de random WRITE access tijden.

Als je je een beetje in de materie had verdiept dan had je geweten dat de random write tijden van SSD's bedroevend slecht zijn. Dit komt omdat een SSD met grotere blokken werkt. Om een bit te veranderen wordt eerst een heel blok ingelezen en daarna wordt het hele blok gewijzigd terug geschreven. Omdat de blokken van de SSD's redeljik groot zijn (volgens mij is die 4K van hierboven wat aan de lage kant) gaat het schrijven van veel kleine bestanden erg traag.

[Fiander]

250ms dat zou 4 write acties per seconde zijn? sorry hoor, maar dat wil er bij mij niet in.

verder zal ELK OS altijd een sector in zijn geheel beschrijven, dus dat er voor 1 bit eerst gelezen moet worden, en dan pas geschreven, prima, maar dat zal dan door het OS geïnitieerd worden, en is op een HDD exact hetzelfde.

Of bedoel je soms dat omdat het OS met 512B sectors schrijft, er eerst door de controller de hele sector opgehaald moet worden om daarna het gedeelte te schrijven wat volgens het OS een sector is ? daar gaat nou het hele artikel over, dat in het OS de sector groote vergroot word, waardoor dit niet meer van toepassing is. ???

[Reactie gewijzigd door Fiander op 27 juli 2024 02:16]

[_js_]

Kijk eens hier: http://www.alternativerecursion.info/?p=106
Echt wel 250ms per random write.

Wat in het artikel hiet op tweakers staat over 512kB sectoren vs 4kB sectoren is niet juist.

Windows werkt met clusters van 4kB, en data staat dus ook in stukjes van 4kB opgeslagen.

SSDs werken met delete blokken van rond de 8 MB. Dat betekent dat als je iets wilt schrijven er 8 MB ingelezen moet worden, aangepast worden en daarna weer weggeschreven. Dus als je een hoop kleine dingen van zeg 4kB wilt aanpassen, en die allemaal over de schijf verspreid zijn, en je dus niet met een schrijfactie meerdere blokken aanpast, dan zit je op een bedroefende snelheid.

Stel leessnelheid van 100MB/s en schrijfsnelheid van 50MB/s.
8MB lezen duurt dus 0,08 seconde en schrijven 0,16 seconde, samen 0,24 seconde.

Het maakt niet uit of je 1kB wilt schrijven of 8MB, het zal altijd 0,24 seconde duren, daarom zijn SSDs in sommige gevallen zo langzaam.

[Verwijderd]

Maar als 2 of meer random writes in een ander erase-block liggen, dan kunnen die twee wel parallel worden uitgevoerd. Dus 1 of 2, beide kennen dan een latency van 250ms. In theorie kun je hier dus een superhoge random write performance van maken, maar de eerste SSD controllers komen nu pas om de hoek kijken dus er zal wel veel potentie verloren gaan. De sleutel tot performance ligt denk ik niet zozeer in het flashgeheugen zelf, maar in de aansturing ervan.

En ik ben benieuwd wat een ICHxR met write-back doet met een SSD, dan zou je toch de eerste 80MB ofzo tegen RAM-snelheid moeten kunnen schrijven, en je een geweldige ervaring geven omdat al die kleine writes heerlijk gebuffered worden en de latency daarvan dus tegen de 0.

Overigens: er zal op windows-systemen vrijwel altijd een misalignment zijn, omdat NTFS op een niet-macht-van-2 begint. Dus als je SSD met 8KiB blokjes werkt en -stel- windows braafjes ook, zal door de misalignment nog altijd voor elke I/O twee blokken op de SSD worden geraadpleegt. Figuurtje:

I/O request: |xAAA|ABBB|BCCC|Cxxx|
SSD blocks: |1234|5678|9ABC|DEFG|

Er worden in dit voorbeeld drie I/O requests gedaan: A, B en C. Te zien is hoe request A zowel de eerste block (1-4) als de tweede block (5-8) 'pakt' en de controller het hele geval van alles lezen en opnieuw schrijven voor twee blokken ipv een moet doen. Dit wordt een filesystem misalignement genoemd, en is vooral schadelijk voor RAID-performance, en dus kennelijk ook SSD's.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 02:16]

[Fiander]

on July 30, 2008 at 3:01 pm Michael wrote:

Dave, run the latest version of Sandra, make sure you have SP1 (vista) installed and after the installation, reinstall the chipset drivers because SP1 seems to nuke the chipset drivers that were installed before the service pack.

I just ran Sandra “before” and “after” and the “before” data are about the same as yours, whereas the “after” data get me some 55 MB/s sequential writes, the random writes are about the same — just a tad higher but that could be just the variability between different runs.

komt uit het commentaar onder het artikel, de schrijver heeft dus een driver probleem geconstateerd. Wat natuurlijk prima kan, want als er echt zoiets aan de hand zou zijn, dan zou Femme het in zijn database benchmark met SDD wel aan het licht hebben gebracht

[Verwijderd]

komt uit het commentaar onder het artikel, de schrijver heeft dus een driver probleem geconstateerd. Wat natuurlijk prima kan, want als er echt zoiets aan de hand zou zijn, dan zou Femme het in zijn database benchmark met SDD wel aan het licht hebben gebracht

Dat is commentaar op een reactie van iemand anders, niet op de tester. Als je wat verder naar boven gaat dan zul je zien dat de poster van deze reactie voor OCZ werkt en toegeeft dat random writes het zwakke punt zijn van SSD's.

[Fjutrackx]

Ja, die link verwijst naar een OCZ. De low budget SSD's
Doe die vergelijking eens met een Mtron?
> 0.1ms acces time ipv 0.35, en ik heb Mtron aan de telefoon gehad.
1 SSD van dat kaliber is zeker sneller dan een seagate cheeta 15krpm.
EN dan zijn de read / write snelheden 130 / 120MBps.
Bij een standaard schijf iets van een 70 / 60 denk ik? en een 2 cheetas in raid 0 halen we 150/130 gemiddeld. Check google

Stel, je zet er enkele in raid 0, (de 7000 en 7500 reeks) gaat ie nog wel wat sneller
Of zoals de echte speedfreak er 9 in raid 0 stak. Kom je met een read / write van 1100/900MB
Beetje overkill

edit*
(Maar naar het prijsverschil moet je niet letten. Een Mtron 64gig komt al snel 600 euro)

[Reactie gewijzigd door Fjutrackx op 27 juli 2024 02:16]

[watercoolertje]

32 tot 30

??????????? (klokje rond ? )

[Fiander]

moet idd 32 tot 40 zijn

[Ibex]

Een nadeel van grotere sectoren is dat de "grootte op schijf" zal vergroten ten op zichte van de "werkelijke grootte" als ik me niet vergis. Stel dat je een bestand van 100 bytes wegschrijft. Momenteel ben je dan slechts 412 bytes "kwijt", in de toekomst ben je dan ongeveer 3900 bytes "kwijt"!

[Fiander]

Nee, je bent die ruimte nu ook al kwijt.
Het OS zal de data niet in een sector plaatsen, maar in een cluster.
en tenzij jij clusters van 512 B hebt, ben je nu al extra ruimte kwijt.

Maar aan de andere kant, bij een bestand van 1MB, zul je bij 512B clusters 2000 verschillende clusters moeten adresseren, en individueel moeten benaderen, terwijl je bij 4K clusters er slechts 250 hoeft te benaderen.

Verder heeft elke cluster een klein stukje overhead, met daarin een ID en dergelijke.
Door zulke kleine (512B) clusters te gebruiken zal je overhead toenemen. het aantal IO's zal toenemen, en je performance afnemen. want hoe vaak benader jij bestanden van 100byte ? en hoe vaak grotere bestanden ?

Juist door het aanpassen van de sector grote naar 4K sluit het een stuk beter aan bij de gangbare cluster grote.

[Reactie gewijzigd door Fiander op 27 juli 2024 02:16]

[Shadow_Dragon]

Is dat nu al niet? Maak maar eens een .txt-bestandje (of iets anders) aan met enkele tekens. Als je nu de eigenschappen van dat bestandje opvraagt zie je staan: 4,00 kB (4.096 bytes)

Windows neemt telkens een veelvoud van 4,00 KiB (1 cluster) om een bestand op te slaan. Zoals Fiander hierboven reeds zei, op dit moment verwacht het OS dat de data wordt doorgestuurd in blokjes van 512 bytes (1 sector op huidige HDD's). Bij SSD's is zo'n sector 4 KiB en dus groter.

Even het mogelijks iets duidelijk te maken:
OS slaat bestand op in x aantal clusters (meestal is 1 cluster = 4 KiB).
Op een HDD is 1 cluster dan 8 sectoren en wordt dus in 8 stukjes van 512 bytes doorgestuurd.
Op een SSD is 1 cluster dan 1 sector en wordt dus 1 stuk van 4096 bytes doorgestuurd.

=> Verlies blijft even groot want de cluster grootte veranderd niet.

* Of sla ik nu de bal compleet mis...

[_js_]

Ja, je slaat hem mis.

Het OS verstuurt gewoon blokken van 4kB als een enkele cluster gewijzigd wordt.

[Fiander]

dat zegt ie toch ook ? het is alleen de driver/io controller op de disk zelf, welke het opbreekt in stukken van 512B

[SvenG]

Goed nieuws, hopelijk komt er dan 'vrij vlot' een patch in de vista update

[SPee]

Alsof de vorige goed heeft geholpen

[loewie1984]

Zo te zien zijn er dus nog wel wat obstakels te nemen: Defragmentatie is er een bijvoorbeeld. Houdt dit dan ook in dat in principe elke niet geoptimaliseerde SSD die nu op de markt te krijgen is, eigenlijk niet geschikt is of simpelweg niet kan voldoen vanwege de bovengenoemde problemen?

Want als je weet dat de SSD's die er nu zijn, door Vista niet optimaal benut kunnen worden, slecht tegen defragmentatie kunnen en ze hierdoor ook nog eens een kortere levensduur kunnen hebben. Dan wacht je als consument of als bedrijf toch tot de schijven wel optimaal en compatible benut kunnen worden. En dat ze beter bestand zijn tegen defragmentatie.

Dus als dit dan geen kat-uit-de-boom kijken verhaal wordt...

[Arcane Apex]

Hoe zit het eigenlijk met de optimalisatie voor SSD's in Linux of Unix?(of ext3)
Is deze reeds beter dan van Windows of moet daar ook nog het 1 en ander aan gebeuren?

[Verwijderd]

zover mij bekend loopt linux hier op achter. dit is wel vaker zo alleen is wel binnen 1 jaar te verwachten dat ook dit binnen de linux com opgelost wordt.

[kozue]

Aangezien defragmentatie als een van de problemen in windows aangegeven wordt, loopt linux in dit geval juist voor, aangezien je die al sinds ext3 niet meer hoeft te defraggen (er zijn zelfs niet eens defragmentatie tools voor linux, want ze zijn nutteloos).
Ook het probleem met clustergroottes is in linux niet of nauwelijks aanwezig, aangezien je daar bij het formatteren zelf je grootte kan kiezen (en de kernel het dus allang al support).
Dit is weer eens een typisch gevalletje van windows die de vooruitgang tegen loopt te houden door te blijven hangen op verouderde technologie (zoals ntfs).

[Reactie gewijzigd door kozue op 27 juli 2024 02:16]

[Pathogen]

Het mooiste zou in mijn ogen zijn het gebruiken van een apart stuk cache in de SSD, waarin het filesystem even netjes uit kan zoeken welke cluster waar geschreven moet worden.

Hoewel je dan misschien weer het enorme voordeel van de lage seektimes teniet gaat doen

Ik brainstorm nog even door

[Fiander]

Word het niet eens tijd dat ook hardeschijf fabrikanten ook overstappen op grotere sectors ?
Het lijkt mij dat je intern in de HDD dan minder IO nodig hebt ten aanzien van adressering.
en daarmee zullen idd oudere systemen niet kunnen werken. maar het zou een winst kunnen geven, of zie ik iets over het hoofd ?

[notsonewbie]

Soft-mirror inbouwen lost dit wel op lijkt me.
Installeren met bijv. 60 MBps op een partite van 4, 8 of 12 GB met kleine sectoren, die de SSD dan ' in zijn eigen tijd' op de snellere (qua lezen) delen over-kopieert, uiteraard wel met behoud van de uiteindelijk benodigde juiste path info! :-) .

Dan heb je snelle installatie, even wat mindere prestatie, maar in no time optimale read.
Is de ' swap met kleine sectors' leeg kan die dus ook gebruikt worden voor de kleine veranderingen van bitjes hier en daar in bijv een word document of wat dan ook.

[Reactie gewijzigd door notsonewbie op 27 juli 2024 02:16]