Linux-kernel 3.9 biedt raid-modi voor btrfs en ssd-cachingmodus
De Linux-ontwikkelaars die aan kernel-versie 3.9 sleutelen, hebben de eerste release candidate uitgebracht. De nieuwe kernel biedt onder andere raid 5- en 6-modi voor het btrfs-bestandssysteem en een nieuw mechanisme om ssd's als cache in te zetten.
Nu met het uitbrengen van de release candidate het zogenaamde release merge window is gesloten, wordt duidelijk welke features versie 3.9 van de Linux-kernel zal krijgen. Een van de nieuwe mogelijkheden is de ondersteuning voor het aanmaken van raid 5- en 6-arrays op basis van het btrfs-bestandssysteem. Zowel btrfs als de native raid-ondersteuning dragen nog wel het label 'experimenteel' en is dus niet zonder risico. Raid 0 en 1, ook bekend als mirroring en striping, waren al wel mogelijk op btrfs-volumes.
Ook interessant op het gebied van storage is een nieuw caching-mechanisme. Daarbij kunnen solid state disks ingezet worden als een cache voor veelgebruikte data als aanvulling op de opslag van harde schijven. Het cachingmechanisme zou vergelijkbaar zijn met de voordelen van een hybride harddisk, waarbij snel flashgeheugen een aanvulling vormt op de doorgaans aanzienlijk grotere opslagcapaciteit.
Een andere in het oog vallende vernieuwing in de kernelcode is een verbeterd algoritme voor LZO-compressie. Zowel op x86- als ARM-systemen zou een aanzienlijke snelheidswinst zijn te behalen bij zowel het comprimeren als het uitpakken van data; zo zou op een testsysteem met een Sandy Bridge-processor en een 64bit-kernel met het oude algoritme 150MB/s worden behaald bij het comprimeren en met het nieuwe LZO-algoritme een snelheid van 434MB/s.
Net als in elke kernelupdate is ook de hardwareondersteuning verbeterd. Zo kan de KVM-hypervisor overweg met de virtualisatiemogelijkheden van courante Cortex A15-cpu's. Ook kan de kernel draaien op processors van de firma Synopsys en Imagination. Verder is er ondersteuning voor nieuwe hardware, waaronder diverse wifi-hardware van Intel.
Reacties (21)
Even voor een leek op dit gebied... Betekent dit dat je in een bestaand systeem met een X-aantal harde schijven dus gewoon een SSD kan kwakken en het systeem gebruikt hem automatisch als cache? Dus je hoeft niet je installatie te verhuizen naar de SSD, en krijgt er een grote stap in snelheid voor terug?Ook interessant op het gebied van storage is een nieuw caching-mechanisme. Daarbij kunnen solid state disks ingezet worden als een cache voor veelgebruikte data als aanvulling op de opslag van harde schijven. Het cachingmechanisme zou vergelijkbaar zijn met de voordelen van een hybride harddisk, waarbij snel flashgeheugen een aanvulling vormt op de doorgaans aanzienlijk grotere opslagcapaciteit.
Precies hoe dit in zijn werk gaat is volgens mij nog niet beschreven maar ik denk dat het wel de bedoeling is dat je hem er gewoon naast kan zetten en via een paar instellingen kan inschakelen.
Heb er nog niet naar gekeken en niks gaat automatisch (zal het wel toe moeten voegen / configen), maar het zal ongetwijfeld een ARC (adaptive replacement cache) zijn zoals ZFS dat ook heeft.
Zal toch nog wel even moeten wachten voor 3.9 uitkomt en bruikbaar is op m'n SANs met LIO (draai wel enigszins bleeding edge met 3.5 maar geen rc
).
Zal toch nog wel even moeten wachten voor 3.9 uitkomt en bruikbaar is op m'n SANs met LIO (draai wel enigszins bleeding edge met 3.5 maar geen rc
).edit:
Hmm gebaseerd op flashcache, maar nog wel de nodige uitbreidingen: http://www.phoronix.com/s...=news_item&px=MTI5MDg was niet kapot van flashcache in ieder geval, hoop dat dit beter is
Hmm gebaseerd op flashcache, maar nog wel de nodige uitbreidingen: http://www.phoronix.com/s...=news_item&px=MTI5MDg was niet kapot van flashcache in ieder geval, hoop dat dit beter is
[Reactie gewijzigd door freaky op 4 maart 2013 19:13]
SSDs als cache worden niet domweg gebruikt om vaakgebruikte bestanden op de SSD te plaatsen, zoals veel mensen denken. In plaats daarvan wordt de SSD gebruikt om snippertjes data op te slaan die middels random reads worden opgevraagd. Technisch gezegd wordt enkel non-contiguous access op de SSD geplaatst. Bestanden die van A tot Z worden ingelezen, worden dus niet gecached.
Naast bestanden cachen is metadata cachen waarschijnlijk nog belangrijker. De metadata is klein van omvang, maar zorgt voor allerlei random reads tussendoor wat voor hardeschijven de snelheid er flink uithaalt.
Het principe van SSD caching is dat de SSD de 'random I/O' voor zijn rekening neemt zodat de hardeschijven zich uitsluitend kunnen richten op sequential I/O ofwel het verwerken van grote bestanden ('contiguous access'). Het mooie hierbij is dat een kleine SSD van 20GB al zo'n 5 miljoen 4K-queries kan cachen. Je hebt dus helemaal geen grote SSD nodig; een kleine SSD kan al heel veel verschil uitmaken.
Het nadeel van SSD caching is:
Naast bestanden cachen is metadata cachen waarschijnlijk nog belangrijker. De metadata is klein van omvang, maar zorgt voor allerlei random reads tussendoor wat voor hardeschijven de snelheid er flink uithaalt.
Het principe van SSD caching is dat de SSD de 'random I/O' voor zijn rekening neemt zodat de hardeschijven zich uitsluitend kunnen richten op sequential I/O ofwel het verwerken van grote bestanden ('contiguous access'). Het mooie hierbij is dat een kleine SSD van 20GB al zo'n 5 miljoen 4K-queries kan cachen. Je hebt dus helemaal geen grote SSD nodig; een kleine SSD kan al heel veel verschil uitmaken.
Het nadeel van SSD caching is:
- Het kost je RAM geheugen om de referenties bij te houden; je filesystem moet weten wat er gecached is op je SSD.
- Corruptie op de SSD kan je data corrumperen. Bij ZFS is dit voldoende afgedekt. Bij Btrfs zou dat ook kunnen maar weet ik niet zeker. Bij Windows vloeit SSD corruptie gewoon door naar je echte filesystem en blijft ongedetecteerd.
- Je bent je caches kwijt na een reboot. Je moet dan weer een cache opbouwen. Voor mensen die elke dag/nacht hun server uitschakelen is dit dus veel minder geschikt.
Hoe werken het tweede en derde punt wat je noemt, samen? Hoe kan een reboot zorgen dat de cache opnieuw opgebouwd moet worden terwijl corruptie op diezelfde SSD mogelijk zou zorgen dat al je data corrupt is? Als die cache opnieuw opgebouwd kan worden, dan moet dat toch ook kunnen als de SSD kapot gaat?
Of heeft dat meer te maken met dat als je SSD cache corrupt is je de verkeerde data terugkrijgt?
Of heeft dat meer te maken met dat als je SSD cache corrupt is je de verkeerde data terugkrijgt?
Het probleem is dat je de (mogelijk beschadigde) data die je van je SSD leest ook weer ergens voor gaat gebruiken. Als je een bestand inleest waarin al een paar bitjes zijn omgevallen, op een ander punt in het bestand een wijziging maakt en dan het resultaat opslaat, dan worden die foute bitjes teruggeschreven naar de harde schijf (waar ze de oorspronkelijke, correcte waardes overschrijven). Als het geen bestand is maar meta-data (bijvoorbeeld een lijstje in welke clusters een bepaald bestand opgeslagen is), dan kunnen hele kleine foutjes (één bit verkeerd) al enorme problemen veroorzaken omdat de interne structuur van het bestandssysteem dan niet meer consistent is; er is met geen mogelijkheid te zeggen wat daar het exacte resultaat van is, maar reken er maar op dat het niet bepaald goed is.
Gelukkig heeft ZFS daarom naast de standaard parity ook checksums. Hierdoor kan je data ook niet corrupt raken als er bad sectors op je hard disk aanwezig zijn. Bij de wat ouderwetse raid methoden was dit niet het geval en werd je goede data kapot gemaakt door verkeerde parity.
Dit heet ook wel silent corruption en dat is een systeembeheerder zijn 'worst nightmare', zeker nu we met arrays werken die tientallen terrabyte's groot zijn.
Dit heet ook wel silent corruption en dat is een systeembeheerder zijn 'worst nightmare', zeker nu we met arrays werken die tientallen terrabyte's groot zijn.
btrfs heeft inderdaad ook die checksums.
Zou fijn zijn als het uit experimental komt, want het lijkt mij echt een super FS.
Zou fijn zijn als het uit experimental komt, want het lijkt mij echt een super FS.
Het was mij niet helemaal duidelijk waarom in de kernel ondersteuning geboden zou worden voor een bepaalde compressietechniek, maar blijkbaar (http://en.wikipedia.org/w...#8211;Ziv–Oberhumer) is LVO de compressie die door btrfs gebruikt wordt voor gecomprimeerde bestandssystemen.
Naast het comprimeren van data op het fileystem is het "root filesystem" ook gecomprimeerd. Als een Linux systeem opstart wordt de kernel aangeslingerd door de bootloader (GRUB of SYSLinux bv.). Daarnaast is er nog een "initramfs" bestand. Dit is een gecomprimeerde "Linux installatie" die de basis van het Linux systeem bevatten. Dit bestand wordt door de Linux kernel uitgepakt waarna hierop het(/een) /init programma (of script) wordt aangeroepen. Dit initramfs bevat dan net de juiste dingen om het systeem op te laten starten, bv. de kernel modules voor de SATA chips in je computer, en het init programma zorgt ervoor dat de Linux kernel ook "in vorm" wordt gebracht om daadwerkelijk op te starten (dus het laden van de juiste kernel modules, het mounten van het root filesystem etc). Hierbij is het dus ook min of meer essentieel dat het initramfs image zo snel mogelijk zijn werk kan doen, dus zo klein mogelijk is en daardoor zo snel mogelijk van de harde schrijf kan worden gelezen. Daarom wordt dit initramfs image meestal ook gecomprimeerd op de hardeschrijf, waarbij LZO denk ik ook de meest gebruikte compressie variant is. En de kernel zal dit dus ook moeten kunnen uitpakken om de boel aan te slingeren.
Edit:
I stand corrected. Arch wat ik gebruikt gaat default inderdaad ook voor gzip compressie op het initramfs. Dit doet natuurlijk wel niet zo veel af aan de originele vraag "waarom compressie in de kernel". Het initramfs is hier een van de voorbeelden van, naast de normale filesystems die on the fly compression (btrfs, ZFS, ...) kunnen doen en andere specifiekere FSen zoals het oudere SquashFS (read-only FS die het filesystem comprimeert tot een file, en volgensmij (vroeger) veel gebruikt voor LiveCDs) en zoals JGC noemt UBIFS.
Edit:
I stand corrected. Arch wat ik gebruikt gaat default inderdaad ook voor gzip compressie op het initramfs. Dit doet natuurlijk wel niet zo veel af aan de originele vraag "waarom compressie in de kernel". Het initramfs is hier een van de voorbeelden van, naast de normale filesystems die on the fly compression (btrfs, ZFS, ...) kunnen doen en andere specifiekere FSen zoals het oudere SquashFS (read-only FS die het filesystem comprimeert tot een file, en volgensmij (vroeger) veel gebruikt voor LiveCDs) en zoals JGC noemt UBIFS.
[Reactie gewijzigd door RobertMe op 4 maart 2013 20:26]
Initramfs wordt vrijwel altijd met een gzip of lzma-compressed CPIO-archief gedaan.
LZO wordt vnml gebruikt voor transparante filesystem compressie. Het is een vrij simpel algoritme dat met relatief weinig processorkracht verwerkt kan worden. Voorbeelden waarin het toegepast wordt is bijvoorbeeld UBIFS, een filesystem gebouwd voor NAND flash: wat je niet hoeft te schrijven hoeft ook niet naar het trage NAND flash geschreven te worden. De extra overhead van compressie haal je ruimschoots terug met het uitsparen van NAND writes.
LZO wordt vnml gebruikt voor transparante filesystem compressie. Het is een vrij simpel algoritme dat met relatief weinig processorkracht verwerkt kan worden. Voorbeelden waarin het toegepast wordt is bijvoorbeeld UBIFS, een filesystem gebouwd voor NAND flash: wat je niet hoeft te schrijven hoeft ook niet naar het trage NAND flash geschreven te worden. De extra overhead van compressie haal je ruimschoots terug met het uitsparen van NAND writes.
Nice! een SSD die als cache geheugen functioneert.. Dit zal in de toekomst veel snelheidswinsten opleveren
[Reactie gewijzigd door RogazP op 4 maart 2013 19:09]
Nu maar hopen dat ze ook eens gaan kijken naar het afhandelen van unrecoverable read-errors bij het rebuilden van RAID-arrays.
De kans op een unrecoverable read-error van harde schijven is tegenwoordig namelijk vrijwel van dezelfde orde als als de hdd zelf, dus dan gaat de kans dat zo'n error optreed tijdens rebuild al aardig richting de 100%. Dat maakt software-RAID eigenlijk best wel onbruikbaar.
De kans op een unrecoverable read-error van harde schijven is tegenwoordig namelijk vrijwel van dezelfde orde als als de hdd zelf, dus dan gaat de kans dat zo'n error optreed tijdens rebuild al aardig richting de 100%. Dat maakt software-RAID eigenlijk best wel onbruikbaar.
Zolang je beschermd bent door redundancy en checksums hoef je niet bang te zijn voor bad sectors. Zo is ZFS vrijwel immuun voor bad sectors ofwel uBER / URE.
Juist hardware RAID is dus onbruikbaar geworden, terwijl geavanceerd software 'RAID' zoals ZFS wél een antwoord kan bieden voor dit probleem en dus een hoge mate van betrouwbaarheid kan bieden met normale consumenten hardeschijven.
Dit was ook de originele gedachte achter RAID: meerdere goedkope minder betrouwbare hardeschijven samenvoegen tot één volume wat wél betrouwbaar is. Helaas kan traditioneel RAID deze belofte niet meer vervullen en heeft het deze belofte eigenlijk ook nooit echt vervuld. ZFS biedt datgeen wat RAID altijd heeft beloofd maar nooit heeft waargemaakt.
Juist hardware RAID is dus onbruikbaar geworden, terwijl geavanceerd software 'RAID' zoals ZFS wél een antwoord kan bieden voor dit probleem en dus een hoge mate van betrouwbaarheid kan bieden met normale consumenten hardeschijven.
Dit was ook de originele gedachte achter RAID: meerdere goedkope minder betrouwbare hardeschijven samenvoegen tot één volume wat wél betrouwbaar is. Helaas kan traditioneel RAID deze belofte niet meer vervullen en heeft het deze belofte eigenlijk ook nooit echt vervuld. ZFS biedt datgeen wat RAID altijd heeft beloofd maar nooit heeft waargemaakt.
ZFS is niet het ultieme filesystem wat men vaak roept. met name het gebruik van ZFS op consumenten drives is gevaarlijk omdat die bewijsbaar vaak foutieve info geven over de status van de data. Daarmee ligt dus datacorruptie onder ZFS wel degeljk op de loer.
Zie ook: http://mail.opensolaris.o.../2008-October/022324.html
Raid en JBOD zijn verschillende zaken. Hardware raid is feitelijk geschikte hardware met een specifieke firmware die de raid bedient en dus per definitie sneller dan Software raid. Het is een kwestie van de firmware aanpassen aan de technische ontwikkelingen. Daarnaast draait een hardware onder linux met bijv 512MB geheugen al perfect en snel.
ZFS daarentegen vraagt ook nogal wat van het beschikbare geheugen. 8GB of meer is normaal.
ZFS draaien op een hardware raid is niet echt gewenst ( of zet die dan tenminste in JBOD modus) ZFS wil eigenlijjk zelf toegang tot de schijven voor betrouwbare werking.
Het heeft de nodige tijd gekost voor ZFS om stabiel te worden en zichzelf te ontwikkelen tot een van de beste ( het best beschikbare) filesystem. Btrfs heeft daar nog een hele weg te gaan en opname in de kernel is dapper maar niet slim vrees ik. Dat is voorlopig nog niet productierijp en dat kan best nog heel wat tijd duren.
Zie ook: http://mail.opensolaris.o.../2008-October/022324.html
Raid en JBOD zijn verschillende zaken. Hardware raid is feitelijk geschikte hardware met een specifieke firmware die de raid bedient en dus per definitie sneller dan Software raid. Het is een kwestie van de firmware aanpassen aan de technische ontwikkelingen. Daarnaast draait een hardware onder linux met bijv 512MB geheugen al perfect en snel.
ZFS daarentegen vraagt ook nogal wat van het beschikbare geheugen. 8GB of meer is normaal.
ZFS draaien op een hardware raid is niet echt gewenst ( of zet die dan tenminste in JBOD modus) ZFS wil eigenlijjk zelf toegang tot de schijven voor betrouwbare werking.
Het heeft de nodige tijd gekost voor ZFS om stabiel te worden en zichzelf te ontwikkelen tot een van de beste ( het best beschikbare) filesystem. Btrfs heeft daar nog een hele weg te gaan en opname in de kernel is dapper maar niet slim vrees ik. Dat is voorlopig nog niet productierijp en dat kan best nog heel wat tijd duren.
Voordeel van deze RAID-mode is dat het net zoals bij ZFS in het filesystem geintegreerd wordt. Door die integratie heb je veel betere kansen op recovery. Bij ZFS bijvoorbeeld kun je gewoon een disk erbij prakken en een mirror van je stervende disk maken. Alle data die niet te lezen is wordt wel gerecoverd met data van andere disks en als je klaar bent knal je gewoon die stervende disk eruit. Dat werkt wel even wat anders dan bij RAID waarbij een disk bij enkele fouten als onbruikbaar wordt gemarkeerd.
Zeer belangrijke release voor Linux en voor btrfs!!
Is die SSD cachingmodus vergelijkbaar met de Fusion Drive op Macs?
Het lijkt hier te gaan om een cache, bij OS X worden de SSD en de harddisk samengevoegd. Als je dus een 100GB flashdrive hebt en een 500GB harddisk dan heb je onder OS X 600GB ruimte en 500GB ruimte in de Linux situatie. Niet vergelijkbaar dus.
Die logica zie ik niet. Kun je dat uitleggen?
Ik denk namelijk inderdaad dat dit min of meer is wat Fusion Drive is voor de Mac.
Ik denk namelijk inderdaad dat dit min of meer is wat Fusion Drive is voor de Mac.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
