Forum Datorkomponenter Lagring Tråd

Stäng inte av "optimise drives"/"optimera enheter" för SSD

1 2
Skriv svar
Permalänk
Medlem
●
Skrivet av FatherOfThree:

Förlåt att jag uttryckte mig fel...

Men att filsystemet tror att en fil består av fragmenterade block borde inte spela någon roll,
eftersom SSDn läser/levererar data med samma hastighet oavsett vad filsystemet tror eller inte tror.
(Eller är jag ute och cyklar?)

Gå till inlägget

Läs mitt stycke ovanför, speciellt det citerade stycket så klarnar det hela

#15558542

Visa signatur

Min spel rigg:FD Define R4|VX 550W|i5 2500K|Corsair LP 4GBX2|Mammabräda P67 Extreme4|GTX 670 windforce|23tum u2312hm
Min gamla/HTPC:AMD 6000+|Ram 2GbX2|Radeon HD5770| XFX 450/nu XFX 550
Mitt bygge: ByggloggFri frakt INET:Fraktfritt sweclockers vid köp över 500kr

#Gilla inlägg som är bra & Använd citera/@"namn" vid snabbt svar

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av teejee:

Jag är väl insatt i hur SSD fungerar i stort, men vad är konsekvenserna av ett kraftigt defragmenterat filsystem på OS-sidan? Det verkat vara stort motstånd att diskutera det
Även om en SSD är gjort för att alla block kan ligga huller om buller så är nog knappast NTFS optimerat för det. Jag tror inte alla tänker på hur seperata världar SSD och filsystemet är.

Ett exempel:
En stor fil i ett fragment i filsystemet (obs jag pratar om OS-sidan här, ej SSD-sidan) blir väl antagligen en läsbegäran till SSD via SATA. Men om samma fil består av 1000 fragment i NTFS, vad blir nackdelarna med det? Jag misstänker att det blir 1000 läsbegäran till SSD, eller? Ködjup i AHCI/SATA är väl 32 anrop? Skapar detta prestandaförsämring någonstans i systemet (SSD, sata-driver, filsystem etc)
Hur påverkas MFT av en mkt stor mängd fragment?
Osv...

Jag påstår inte att det är ett stort problem, men samtidigt är det ett minimalt problem att göra defagmentering på SSD. Och det är olika parter inblandade, rekommendation att inte defragmentera kommer från SSD-tillverkarna för att minimera slitage, konsekvenser på filsystemet är beroende av filsystem som är en helt annan spelare.

Men visst är det trim som är det centrala, det är ju mkt lätt att mäta effekterna av det.

Gå till inlägget

Förstår vad du menar, men denna fragmentation påverkar endast hårddisken om du inte gör en dum LBA adressering, en sektor efter en annan, något som inte sker idag i normala fall. (Utom tex i en benchmark test)

Visst har du rätt att ett fragmenterat filsystem kan påverka, men dagens SSDer klarar 10k IOPS eller ända upp till 100K IOPS. Så även om filen är utspridd i 1000 delar så kan den hämta dessa väldigt fort, <<1 sek. Sen ligger allt redan fragmenterat på SSDn, så även när det är sekventiellt i filsystemet så är det fragmenterad läsning på SSDn. Så åter, den lilla vinst som sker, är så liten att den inte hjälper mer än den faktiskt skadar.

När lågnivån av filsystemet begär en fil så begär det antingen hela filen (och då alla LBAs), eller en viss sektion (LBA Adress) beroende på om den tex ska läsa prestandan i RAW, eller själva filen. Detta vidarebefordras sen till disken. Varje sådan är ett anrop. Du kan göra upp till 32 st samtidigt. SSDn kan dock hantera upp till 10k+ varje sekund...

Så om nu adresseringen av gamla fragmenterade filer blir lite långsammare så pratar vi millisekunder, inte ens en sekund av den värsta tänkbara fragmentering. Därför är det fortfarande inte lönt att göra detta.

Det som gjorde HDD långsam på detta var att den var tvungen att gå tillbaka till MFT för att se var den skulle hitta nästa del (nästa LBA) när en fil var fragmenterad. I en SSD så gör den dessa operationer parrallellt, och fördelar lasten mellan alla NAND (och försöker läsa från alla NAND samtidigt). De flesta diskar kan idag även med 64k läsning maxa Sata3, och i 4k iaf nå hälften av Sata3. Så den filsystems-påverkan är extremt minimal.

Redigera
Citera flera Citera
1 2
Skriv svar