Spørgsmål ang. btrfs
Hej
Jeg går og leger med ideen om at lave en linux hjemmeserver og i den forbindelse har jeg et par spørgsmål ang. filsystemer. Jeg er ret fascineret over zfs og de muligheder det giver, her tænker jeg især på raid-z hvor man kan lave et raid med harddiske af fortællig størrelse. Da jeg gerne vil bruge linux er zfs ude af billedet og jeg er derfor begyndt at se mig omkring efter andre muligheder. I min søgen har jeg fundet btrfs, som virker til at kunne blive et godt alternativ til zfs.
Mit spørgsmål ligger i hvorvidt om brtfs i sin nuværende stand kan levere noget lignende raid-z eller om det er en funktion der kommer senere? Yderligere kunne jeg godt tænkte mig at vide om det bliver muligt tilføje ekstra diske til sit raid eller om man er begrænset til at udskifte de eksisterende men nogle større.
Håber i kan hjælpe :)
Jeg går og leger med ideen om at lave en linux hjemmeserver og i den forbindelse har jeg et par spørgsmål ang. filsystemer. Jeg er ret fascineret over zfs og de muligheder det giver, her tænker jeg især på raid-z hvor man kan lave et raid med harddiske af fortællig størrelse. Da jeg gerne vil bruge linux er zfs ude af billedet og jeg er derfor begyndt at se mig omkring efter andre muligheder. I min søgen har jeg fundet btrfs, som virker til at kunne blive et godt alternativ til zfs.
Mit spørgsmål ligger i hvorvidt om brtfs i sin nuværende stand kan levere noget lignende raid-z eller om det er en funktion der kommer senere? Yderligere kunne jeg godt tænkte mig at vide om det bliver muligt tilføje ekstra diske til sit raid eller om man er begrænset til at udskifte de eksisterende men nogle større.
Håber i kan hjælpe :)
Kommentarer27
ZFS
Der er i hvertfald native ZFS-support :-)
#1 er openindiana
Det er altså
Du har 2 muligheder. Hvis du vil have ZFS, så er det OpenIndiana og du hiver al kildekoden igennem gcc og laver OpenSolaris-pakker - eller du bygger noget op på basis af Linux, som du selv er inde på (og må så undvære ZFS).
Jeg har ikke hørt om at btrfs skulle være i brug noget sted.
Vent lidt. Jeg kommer i tanke om at der findes en ZFS-implementation til FreeBSD. Det er ikke noget jeg har kigget nærmere på, dog. Tanken kom af at jeg tænkte tilbage på et Varnish-foredrag hvor Poul-Henning Kamp nævnte Linux og FreeBSD som de eneste moderne Unix-kernels. Det var selv samme udtalelse der er årsag til at jeg ikke selv har valgt OpenIndiana som mulighed til et server-OS. Indtil videre fortsætter jeg med Linux og XFS.
btrfs er stadig under
Jeg har gennem længere tid kørt btrfs på en 2TB disk, men er lige gået væk fra det i dag da jeg gerne vil bevare min data og nogle gange løb ind i et par ubehagelig og kendte bugs*.
Jeg har ikke forsøgt at bruge nogle af de mere avancerede features i btrfs, så jeg kan ikke sige ret meget om dem.
*) Nogle gange låser filsystemet, så der ikke kan skrives eller læses fra det. Eneste løsning på dette er en hård genstart.
Du kan installere en Fuse
http://zfs-fuse.net/
Ellers er der en RC udgave af en integreret ZFS løsning her.
http://zfsonlinux.org/
Og sidst en LLNL ZVOL implementation af ZFS (Hvad f* det så end er), Læs mere om den her.
http://www.phoronix.com/scan.php?page=article&item=linux_kqzfs_benchmar…
Btrfs kan du læse om her.
http://en.wikipedia.org/wiki/Btrfs
LVM?
LVM er ikke et filsystem men en volume manager.
ZFS og Linux
btrfs kan også lave noget,
btrfs er dog ikke stabilt endnu og mangler, som det er blevet nævnt, bl.a. et fsck værktøj til at tjekke filsystemets tilstand. Jeg har dog aldrig brugt ZFS andet end ekstensivt, hvorfor jeg ikke kan sammenligne dem andet end overfladisk.
Er enig med #6. Kig på
Efterfølgende kan du forstørre, formindske (om end det er lidt mere besværligt end at forstørre), slette, oprette nye, logiske drev løbende. Du kan også tilføje nye hardiske til gruppen, eller skifte en eksisterende ud med en større. Man kan også fjerne en disk, såfremt der er nok plads på de andre diske til at det date kan flyttes der over.
Jeg tror jeg skal have
Det er rigtigt at lvm kun
Optimalt kør raid 10
hvis du vil sparer kør raid 1.
Læs eventuelt:
http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
Men hvis du så alligevel gerne vil kører raid5, så kan du lave en raid 5 array med md (linux standard software raid værktøj) og tilføje hele dit raid array til din volume group i lvm. Så kører du raid 5, mens du stadig kan brug lvms fleksibilitet.
Denne løsning er i øvrigt også en mulighed for raid 1 og 10, hvis man hellere vil bruge md end lvm til at styre raid delen.
raid10,f2 er raid1 - men dobbelt så hurtigt ved læsning
Keep it simple
raid 1 5 6 10 whatever.
Man skal bare lige forstå konceptet og her er der masser af god dokumentation.
Alt det her raid snask og mirroring osv bliver hurtigt meget komplekst , og der er tonsvis af filsystemer som kan sprede sig over mange fysiske diske og lave alverdens trolddomstricks.
Du skal finde ud af hvad du vil have ud af dit storage system. De fleste vil bare have et fire and forget system hvor de er nogenlunde sikret mod disksnedbrud og config fejl. I så fald lav et raid1 hvor alt er på begge diske, sørg for at gem info om opsætning af LWM på en anden maskine så du kan moute derfor, og skaf en 3 disk til backups når du kommer til at slette en fil og dit topsnedige raid system bare siger,, jamen du bad mig om det, så har du en backup.
Da diske til masser af skrammel pt koster 500 dkr for 2TB , er prisen ikke det altafgørende. inden du har fiddlet med dit raid5 så har du brugt mandetimer nok til bare at købe flere diske. Er dit data rent faktisk vigtigt , jamen så er chancen høj for at det er værd at kaste penge efter til flere og eller bedre diske.
#12
Det vi mener er lvm i
Det vi mener er lvm i sig selv kan lave raid 1 eller 0 på en logisk volume uden brug af md.
Selvfølgelig kan man ligge en hvilket som helst md device ind, og derved opnår alle former for raid.
Men hvis man alligevel skal bruge lvm, og man kun skal have raid 0 eller 1, kan man, efter ming mening, og din nævnte keep it simply princip, lige så godt sparer et lag, og lade lvm selv klarer raid håndtering.
Modsat kan man argumentere for, at md er ældre end lvms raid understøttelse, og derved mere gennemtestet.
mdadm
Kan mdadm håndtere uens disk størelser i samme raid?
Tak for alle de gode svar
http://www.flexraid.com/
#15
Nu blev der nævnt raid5 , som efter min mening er gak til simple hjemmesetups, dels har man behov for 3 diske , dels er det mere kompliseret at vedligeholde og umiddelbart er write performance værre end raid1 og read performance ikke bedre. og du kan stadig kun tål at miste 1 disk men har 3 der kan gå i stykker.
Til sidst er der den klassiske at man har et raid5 hvor den ene disk ryger , imellemtiden kværner du ekstra på de resterende diske til brug for recovry eller til alm læsning og så dør disk nummer 2 (da alle 3 diske formentligt er af samme alder) og så ryger hele dit raid
Ja disk nummer 2 der ryger
I den forbindelse kan jeg anbefale at bruge diske fra forskellige fabrikanter, de vil typisk ikke have lige lang levetid og gør derfor det scenarie mindre sandsyndligt.
#0:
jeg vil anbefale dig
jeg vil anbefale dig bare at lave linux md + xfs. glemt lvm2 medmindre du VIRKELIG har brug for noget i den stil.
hvilken level du skal have afhænger af dit behov, jeg bruger selv raid6 over 8x1tb diske på min filserver.
#12:
wtf? mange mandetimer? du kan sgu da lave et raid5 eller hvilket som helst andet raid level linux understøtter på omtrendt 10 sec.
#17:
det er lidt uddaterede holdninger..
raid5 har ganske fin performance i nondegraded mode, husk på, vi sidder sgu ikke på IDE og 50mhz p1 maskiner idag. vi har uendeligt cpu og massere båndbredde på sata/pcie
desuden, hvis din second disk dør under rebuild af et raid1 eller raid10, mister du også.
bare brub raid6.
Der er godt nok ikke ret
Ang. btrfs så har det samme feature set som ZFS ja, men btrfs kan på nuværende tidspunkt kun levere raid 0 og 1. Desuden findes der intet fsck der til endnu.
Ang. ZFS er den bedste linux implementation lavet af KQ infotech (som dklinux kalder LLNL), og kan hentes via github. Men stadigvæk så er det ikke særligt godt i forhold til hvad du kan få på et solaris system med nativt support.
FreeBSD giver den næste bedste implementation men det er bare heller ikke godt nok, det er først i 9.0 hvor zfs er standard. Dog stadigvæk mangler der lidt speed i forhold til hvad man kan hive ud af solaris.
Ang. Flexraid så er det objekt storage, lukket software der er i beta i øjeblikket. Jeg vil ikke røre det fordi at det ikke er open source, når betaen lukker.. så er du fucked. Med mindre du vil betale
Men teknisk set kan det det samme som et hvert andet raid5 system bare på objekt niveau frem for block niveau.
-G
ikke helt korrekt.
Raid 10 går ikke nødvendigvis ned hvis disk nummer 2 dør, det afhænger af hvilken af de restende 3 diske der går ned. Det er kun 1 bestemt af de 3 tilbageværende der ikke må stå af (for udsat det er bestående af 4 diske).
nej
Og ZFS,, nej tak , oracle har ikke givet mig lyst til at se på solaris, desværre anfører de også btrfs udviklingen.
#19
nej, det er ikke ud-daterede,, at du så brænder flere CPU cycles og har det fint med det ændre ikke på at de operationer der skal til for at skrive og lave partitions info er en lille smule mere kompliseret end raid1 og at det næppe kan detekteret på nogle af de slagskibe af CPUer selv almindelige mennesker sidder med ændrer ikke på at den relative performance er dårligere.
du siger raid6 , jeg siger mere komplekst.
Kapaciteten er umiddelbart antal-disks minus 2 ( alt efter hvor snedig paritets-algoritmen er) . Så her er det først rigtigt interessant ved 5 diske eller mere i forhold til raid5. Ved 8 diske kan jeg godt forstå valget . Vores user her mangler at fortælle hvor komplekst han vil have det og hvor mange diske han regner med at ville bruge på det.
#21, enig men ingen har lyst til at kaste den mønt.
Uanset:
husk ups og backup
#22:
raid6 er ikke rigtig
raid6 er ikke rigtig mere komplekst, og faktisk kan en raid6 implementation laves så den matematisk er mindre komplekst end raid5 (dog gør linux md ikke brug af dette).
raid10 i linux(raid10, ikke raid1+0) kræver kun 2 diske, og i dette setup vil du miste data hvis næste disk dør under rebuild.
performance er desuden ikke dårligere, da du ultimativt med idags diske og cpu osv får samme i sidste endnu, bare med højere cpu/bus forbrug. noget der er irellevant, desuden er performance ikke dårligere, da du får mere, men dermed også skal lave mere.
forestil dig en lastbil, hvis du hælder mere gods i den, bruger du mere benzin på at fragte, men performance er da ikke dårligere, du får jo mere for det. faktisk vil det formentlig blive set som bedre.
Det er rigtigt at raid 10 i
RAID TEN IS : dot dot dot
Linux raid 10 med MDadm (julemand ) er en snedig bastard der spreder partitionens data chunks og mirror chucks sekventielt med disk antallet og partititets antallet, så du kan få variaben sikkerhed og performance i virkeligheden er det en blanding af raid0 1 og 1E. Du kan fx sprede den over 3 diske(raid 5 ish), eller over 5 med dobbeltpartitet (uhhh raid 6 wannabe). I må kalde det trylleraid eller pissefed diskstruktur for min skyld.
Lastbils analogien :
hvis en algoritme bruger flere resourcer på at lave det samme så performer den dårligere. hvis lastbilen bruger mere brændstof på at transportere det samme så performer den dårligere.
Det du tænker på er at pladstabet er væsentligt mindre med raid 5 eller 6 ,, men at du har mere lager kapacitet gør ikke at dette data i sig selv bliver flyttet eller siger noget om hvor effektivt dette bliver flyttet .
Mener du derimod båndbredde for lastbilen som udtryk af lagerkapacitet x hastighed er der noget om det . Men ved lastbilen får du båndbredde for dine ekstra dråber benzin ved raid niveau får du ikke ""nødvendigvis"" transfer båndbredde men derimod bedre dataintegritet ved fx raid5.
Bottomline af alt det her flueknep, ikke vild med endnu en "bil" analogi
Har ikke set implementationen af raid5 vs raid6 muligt at raid6 kan kodes pænere (mere effektivt) da partiteten bliver delt anderledes ud.
I får et gratis byg selv gmail baseret raid 10 af mig hvis i gætter filmen jeg refererer til i titlen (sponseret ufrivilligt af Google Inc. [TM])
#25:
men nu er det jo heller
men nu er det jo heller ikke det samme den performer. raid6 giver dig MERE end raid5. ikke diskplads, men datasikkerhed.
desuden har raid6 en feature som (desværre ikke ret tit er brugt i implementation) er raid5 totalt overlegen, og her snakker vi ikke bare småt.
forestil dig med raid5. du har i teorien 2 kopier af alt data. hvad hvis checksum ikke er ens på begge? så må du bare bide i æblet, og overskrive den ene kopi med den anden, altså 50% chance for at gøre forkert.
forestil dig nu raid6. vi har 3 forskellige kopier af dit data(ved godt det, ligesom med raid5, ikke er fulde kopier, men sammensætninger). hvis nu checksum på en af kopierne varierer fra de andre, kan du jo med ret stor sandsynelighed sige at de 2 kopier som matcher med checksum, er korrekt, og så overskrive den ene variende sammensætning.
raid6 er simpelthen raid5 totalt overlegen.
note: linux raid6 gør IKKE brug af denne metode på nuværende tidspunkt
raid10
"Linux raid 10 med MDadm (julemand ) er en snedig bastard der spreder partitionens data chunks og mirror chucks sekventielt med disk antallet og partititets antallet, så du kan få variaben sikkerhed og performance i virkeligheden er det en blanding af raid0 1 og 1E. Du kan fx sprede den over 3 diske(raid 5 ish), eller over 5 med dobbeltpartitet (uhhh raid 6 wannabe). I må kalde det trylleraid eller pissefed diskstruktur for min skyld."
Det er rigtigt at Linux MD raid10 er noget andet end hvad der ofte kaldes RAID 10 - men som retteligen bør kaldes RAID1+0. Men så begynder uklarhederne i det ovennævnte. Linux MD raid10 har 3 forskellige layout:
"near" - et layout der er nærmest identisk til RAID 1+0 for lige antal diske, men som også kan have et ulige antal diske.
"far" - et layout hvor det første lag af de yderste og dermed hurtigste diskblokke er et RAID0 array, og det andet lag så er en spejling af det første lag - også som et RAID0. Da man ved læsning kun bruger det første lag, får man læsehastigheder som RAID0 - samt fordele af kun at bruge de hurtige diskblokke. Dette er ved læsning ca dobbelt så hurtigt i mange tilfælde end alle andre spejlede RAID-typer.
"offset" - et layout der giver lidt mulighed for striping, og som er bedre for SSD.
Der er ikke noget med paritet, eller dobbeltparitet som i RAID5 og RAID6.