Voor je partitioneer tool is je raidconstructie transparant. Dus net zoals altijd een partitie maken, alleen niet de maximale grootte kiezen.
Over het nut van onderpartitioneren wordt nog wel gediscussieerd. Mijn idee is dat het uitstel, en geen afstel, van performancedegradatie is. Dus alleen doen als je de ruimte niet nodig hebt.
* Maakt het nu nog uit in welke SATA poort die SSD's zitten? Dat dacht ik ergens gelezen te hebben?
Dat was voor het wedermaagdelijk maken van Intel SSD's met secure-erase. Die snapt alleen drives aan SATA poort 1 t/m 4. (En alleen als ze in compatible IDE mode draaien kwam ik na 2 uur achter Grrrrrr)
McKaamos schreef op maandag 07 september 2009 @ 22:01:
Hoe zit het eigenlijk met TRIM ondersteuning op de geintegreerde RAID controllers van moederborden? Kwestie van een driver update?
En de garbage collection die tegenwoordig steeds vaker wordt ingebouwd in de drive firmware, doet die niet eigenlijk hetzelfde als TRIM?
Volgens mij is niemand er echt uit hoe het zit met TRIM support op onboard RAID.
GC doet niet hetzelfde als trim.
De ene GC is de andere niet. Implementatie verschilt per fabrikant.
In theorie: GC kan deels beschreven blokken bij elkaar voegen zodat er weer een nieuw snel te beschrijven vers blok is. En kan blokken waarvan de SSD weet dat die zijn bijgewerkt opschonen. Bij een update zal - indien mogelijk - de SSD niet de data echt bijwerken, maar de oude entry ongeldig/leeg markeren en de heleboel in een maagdelijk blok wegschrijven. Dit i.v.m. schrijfperformance.
Wat GC niet kan - tenzij je er eentje hebt die je filesystem gaat interpreteren - is bepalen of een blok hoort tot een file die gedelete is. En juist daarvoor dient TRIM.
Overigens zal TRIM in de praktijk niet zozeer de delete uitvoeren, maar slechts doorgeven dat een bepaald blok vrijgegeven kan worden. De GC doe dan alsnog het eigenlijke delete-werk.
Kom op zeg. Google?
[
Voor 48% gewijzigd door
Titusvh op 08-09-2009 14:59
. Reden: merge ]