Het verschil is dat Linux en BSD gewoon goede eigen RAID functionaliteit hebben. Bij Windows ben je in de praktijk aangewezen op vendor-specifieke drivers die RAID-support 'erin proppen'. En dat doen ze door het als SCSI schijf aan de kernel de koppelen, grofweg gezegd. Dat is viez 'hackwerk'.
Ik weet niet héél precies hoe het bij Linux werkt, dus laat ik me beperken tot FreeBSD. Ik neem aan dat Linux daar sterk op lijkt, maar FreeBSD is net iets geavanceerder door het stoere GEOM storage framework.
Door een mooi 'framework' te hebben voor storage kun je leuke dingen doen. Je kunt een 'chain' hebben van verschillende devices (geom providers) die aan elkaar gekoppeld zijn. Visueel kan dat bijvoorbeeld zijn:
Hardeschijf (/dev/ada2)
-> GPT partitie laag (/dev/ada2p1)
-> GPT labelnaam (/dev/gpt/SamsungSSD)
-> Software RAID0 laag (/dev/stripe/ssdRAID)
-> Encryptie laag (/dev/stripe/ssdRAID.eli)
-> UFS filesystem met TRIM enabled
Dit is een lange chain, maar hopelijk begrijp je het dan beter. Aan het einde van de chain worden TRIM-requests gegenereerd wanneer je iets verwijdert. Die worden echter niet 'TRIM' genoemd maar 'BIO_DELETE' commando's, net als BIO_READ of BIO_WRITE commando's zijn.
GEOM is modulair; modules communiceren met elkaar als een ketting
Dus je hebt niet simpelweg reads en writes, maar ook delete commando's. Deze worden 'down the chain' gestuurd. Dus de encryptie-laag zal deze als eerste zien en doorsturen naar de RAID0-laag. Net als een read-request die over twee schijven verspreid ligt, zal de RAID0 laag nu de BIO_DELETE moeten opsplitsen, wat het ook moet doen met read en write requests; zelfde geval.
Zodra de BIO_DELETE de 'ada' driver bereikt, wat de AHCI ATA driver is, zal deze BIO_DELETE omtoveren tot een ATA TRIM commando. De 'ad' driver zal het CompactFlash equivalent gebruiken en de 'da' scsi driver zal afhankelijk van de instelling UNMAP of soortgelijke 'discard' commando's sturen naar de SSD.
Kortom, de support in FreeBSD is zoals het hoort, een mooi framework waarin dus ook automatisch alle extra modules TRIM/UNMAP ondersteunen, en dat er niet later 'bijgehackt' hoeft te worden. Hackwerk is vies, een mooi framework is beter.
Linux en TRIM
Dit geldt voor FreeBSD, GEOM is BSD-specifiek. Maar Linux zal qua RAID0 laag hetzelfde werken. In tegenstelling tot Windows ziet Linux namelijk wel degelijk de twee fysieke schijven en communiceert hier direct mee en niet via een vendor-only driver.
Dus software RAID (niet alleen RAID0 ook andere vormen) met non-windows OS werkt prima inclusief TRIM en tegenwoordig ook UNMAP support. Wel dient je filesystem dergelijke commando's te genereren. FreeBSD UFS en Linux Ext4 ondersteunen dit, maar je moet het wel handmatig instellen in de /etc/fstab (de 'discard' optie activeren). Hopelijk wordt dit een keer standaard, zodat SSDs out of the box perfect werken met of zonder RAID in Linux/BSD.
Hardware RAID en TRIM
Maar bovenstaand trucje gaat niet op als je hardware RAID gebruikt; dan heb je gewoon géén TRIM support en ik zie dat niet snel veranderen. Het zou wel kunnen, als er UNMAP commando's naar de (scsi) controller gaan en deze vervolgens ze zou omzetten naar ATA TRIM commando's. Maar ik zie het niet gebeuren.
@Swordlord:
Ik weet niet héél precies hoe het bij Linux werkt, dus laat ik me beperken tot FreeBSD. Ik neem aan dat Linux daar sterk op lijkt, maar FreeBSD is net iets geavanceerder door het stoere GEOM storage framework.
Door een mooi 'framework' te hebben voor storage kun je leuke dingen doen. Je kunt een 'chain' hebben van verschillende devices (geom providers) die aan elkaar gekoppeld zijn. Visueel kan dat bijvoorbeeld zijn:
Hardeschijf (/dev/ada2)
-> GPT partitie laag (/dev/ada2p1)
-> GPT labelnaam (/dev/gpt/SamsungSSD)
-> Software RAID0 laag (/dev/stripe/ssdRAID)
-> Encryptie laag (/dev/stripe/ssdRAID.eli)
-> UFS filesystem met TRIM enabled
Dit is een lange chain, maar hopelijk begrijp je het dan beter. Aan het einde van de chain worden TRIM-requests gegenereerd wanneer je iets verwijdert. Die worden echter niet 'TRIM' genoemd maar 'BIO_DELETE' commando's, net als BIO_READ of BIO_WRITE commando's zijn.
GEOM is modulair; modules communiceren met elkaar als een ketting
Dus je hebt niet simpelweg reads en writes, maar ook delete commando's. Deze worden 'down the chain' gestuurd. Dus de encryptie-laag zal deze als eerste zien en doorsturen naar de RAID0-laag. Net als een read-request die over twee schijven verspreid ligt, zal de RAID0 laag nu de BIO_DELETE moeten opsplitsen, wat het ook moet doen met read en write requests; zelfde geval.
Zodra de BIO_DELETE de 'ada' driver bereikt, wat de AHCI ATA driver is, zal deze BIO_DELETE omtoveren tot een ATA TRIM commando. De 'ad' driver zal het CompactFlash equivalent gebruiken en de 'da' scsi driver zal afhankelijk van de instelling UNMAP of soortgelijke 'discard' commando's sturen naar de SSD.
Kortom, de support in FreeBSD is zoals het hoort, een mooi framework waarin dus ook automatisch alle extra modules TRIM/UNMAP ondersteunen, en dat er niet later 'bijgehackt' hoeft te worden. Hackwerk is vies, een mooi framework is beter.
Linux en TRIM
Dit geldt voor FreeBSD, GEOM is BSD-specifiek. Maar Linux zal qua RAID0 laag hetzelfde werken. In tegenstelling tot Windows ziet Linux namelijk wel degelijk de twee fysieke schijven en communiceert hier direct mee en niet via een vendor-only driver.
Dus software RAID (niet alleen RAID0 ook andere vormen) met non-windows OS werkt prima inclusief TRIM en tegenwoordig ook UNMAP support. Wel dient je filesystem dergelijke commando's te genereren. FreeBSD UFS en Linux Ext4 ondersteunen dit, maar je moet het wel handmatig instellen in de /etc/fstab (de 'discard' optie activeren). Hopelijk wordt dit een keer standaard, zodat SSDs out of the box perfect werken met of zonder RAID in Linux/BSD.
Hardware RAID en TRIM
Maar bovenstaand trucje gaat niet op als je hardware RAID gebruikt; dan heb je gewoon géén TRIM support en ik zie dat niet snel veranderen. Het zou wel kunnen, als er UNMAP commando's naar de (scsi) controller gaan en deze vervolgens ze zou omzetten naar ATA TRIM commando's. Maar ik zie het niet gebeuren.
@Swordlord: