Dansk filmselskab får filserver til lavpris med Opensolaris og SSD

Det varmer mit hjerte med en historie om OpenSolaris og ZFS her fra Danmark.

Kan der måske gås mere i dybden med, hvorledes deres zpools osv er sat op? Det vil være rigtig interessant.

Jeg benytter selv OpenSolaris derhjemme på min server (som også snart skal have mere plads), og det er et system som er klippe stabilt, hurtigt og bare spiller.
ZFS er en leg at arbejde med.

Der findes flere muligheder. En af dem er at bruge NexentaStor som er et fuldt storage system bygget på opensolaris og zfs. Den deler mange af de features som Sun S7000 serie har.

http://www.nexentastor.org/

Men jo zfs er super til sådan noget :-)

I know ;-)

Men jeg var mere interesseret i deres konkrete disk setup og allokering - end om de benytter Nexenta, EON eller hvad de bruger?

Nikolaj, vi benytter OpenSolaris snv_133 lige nu.

Vi har to servere som er stort set identiske. Den ene står i huset, det er den der har SSD diske. Den anden står off-site, og der replikeres løbende til den.

Maskinen der står i huset, har en pool med 3xRAIDZ (á 5 diske), og den som står offsite, har 15 diske i et stort RAIDZ2. Sidstnævnte er ikke ligefrem anbefalet, men vi får meget fin performance til backup.

Der er desuden kompression på maskinen som står off-site, hvilket p.t. giver ca. 1.6:1 komprimering - hvilket forærer os en masse gratis plads.

Alle ansatte i huset har desuden adgang til samtlige snapshots ved Windows' VSS (Shadow Copy), og gamle filer/mapper kan nemt fiskes ud af filserveren ved at højreklikke på en vilkårlig fil/mappe og vælge "Previous versions" - smart.

Spørg endelig hvis I har flere spørgsmål.

/Kasper Bræmer-Jensen
Copenhagen Bombay

Kasper, vil det sige at I ikke har noget komprimering slået til på den server som står på Jeres kontor?
Det kan varmt anbefales at sætte "compression=on", som aktivere LZJB komprimering, det er en meget simpel komprimering som giver en smule plads besparelse og bedre ydelse, da mindre data skal læses fra diskene. Se evt. de her links:
http://blogs.sun.com/observatory/entry/zfs_compression_a_win_win
http://don.blogs.smugmug.com/2008/10/13/zfs-mysqlinnodb-compression-update/

Er der i øvrigt nogen grund til I kører build 133 i stedet for build 134, og har I overvejelser om at aktivere deduplikering?

@Kasper
Tak, jeg vender nok tilbage med flere spørgsmål.
* Har i Macs tilsluttet eller er det Windows only?
* Bruger kernel CIFS/SMB eller benytter i SAMBA serveren?
* Bruger i NFS?
* Hvad er prisen pr. GB i jeres setup?
* Hvor længe regner i med løsningen holder inden en upgrade/udskiftning?
* Hvad er jeres upgrade path?

Er I en del af den danske brugergruppe?

Jeg bruger selv SAMBA da jeg alligevel skal have printdelen med - henover CUPS selvfølgelig. Regner dog med at prøve at lave rå netværksprintere uden SAMBA, men direkte til CUPS fra Windows (det virker jo fint fra Linux og Mac - men jeg alle platforme at tage hensyn til).
Derudover kører min server DHCP & BIND DNS (plus en masse andet).
Når der kommer flere og bedre wifi drivere bliver den også til wireless router.

Jeg forstår faktisk ikke at flere ikke benytter ZFS og mulighederne for at lave super NAS med det.
Alt for mange gange smides pengene efter SAN, som mange gange ikke er nødvendigt.
OpenSolaris+ZFS NAS og iSCSI kan i mange tilfælde nemt løse en del af de problemer til en brøkdelen af prisen, som et HP SAN f.eks. koster.
Det er for det meste problematikken i større driftsorganisationer. Der er jo ingen problem med at starte på ZFS NAS, og senere migrere til SAN skulle behovet opstår. Det er bare at flytte data og remounte.
Der er slet ingen grund til at bruge SAN i dev, test osv. miljøerne.

Jeg har sat en del filservere op til backup med Nexenta. Dell MD1000 med 15 1TB diske i raidz2 med dedup. Det sparker intet mindre end rumpe.

@Jeppe, vi bruger pt. gzip komprimering på vores backup, det giver en lille smule bedre kompression ifht. LZJB. Jeg har overvejet LZJB på filserveren på kontoret, og jeg tror du kan have ret i at det kunne spare lidt plads og muligvis give lidt ekstra performance. Må hellere få testet lidt på et tidspunkt, det er jo ikke ligefrem svært at slå til/fra, selv i produktion.

Der er ingen egentligt grund til at vi kører snv_133 fremfor 134 - bør få opgraderet på et tidspunkt, men venter nok til næste egentlige release.

Deduplikering har været overvejet på vores backup server (naturligvis sammen med komprimering), men blev fravalgt da det endnu ikke virker helt modent til produktion - jeg har læst en del skrækhistorier på zfs-discuss listen, med sletning af fx snapshots, som tager dage, sågar uger, før de er væk. Desuden ville deduplikering næsten kræve at der blev installeret minimum 320GB SSD i maskinen, til L2ARC - til dedup tabellen. De koster for mange penge, i forhold til hvor meget diskplads jeg umiddelbart vil estimere vi kan spare med deduplikering.

@Nikolaj, vi har et blandet Windows/Mac/Linux miljø. Alt bruger authentication sker mod vores AD, og ACLs på filsystemet virker helt perfekt imod denne.

I dag bruger vi kernel CIFS/SMB, men havde en del mystiske problemer med den for en måneds tid siden - se evt.http://goo.gl/QhZw - det er åbenbart en hidtil ukendt bug som Oracle arbejder på at få rettet. En planlagt test af en UPS (og dermed nedlukning/restart af serveren) løste dog problemet - og er ikke rendt ind i det siden.

Vi bruger NFS til et par andre servere, men 99% af dataen der flyttes, er CIFS/SMB.

Prisen pr. GB - uhm.. Under 3 kroner, og en del mindre hvis man medregner den gratis komprimering der sker på backup serveren.

I forhold til opgradering, så håber jeg at vores nye kan holde omkring 3 år. Performance og kapacitet kan løbende øges ved at spænde flere diskarrays for, eller evt. udskifte de nuværende 2TB diske med større diske i fremtiden. Begge servere er dual quadcore Intel Nehalem baserede maskiner, og filserveren på kontoret har 48GB RAM at gøre godt med. Vi kan desuden løbende udvide med flere SSD diske til read caching, uden at det koster en formue. Og hvis vi får brug for større performance til sync skrivninger, kan vi evt. sætte flere X25-E'er i, til zil/slog.

Umiddelbart var jeg ikke klar over at der fandtes en decideret brugergruppe for OpenSolaris folk her i landet? Fortæl venligst mere :)

Jeg er desuden fuldstændigt enig i omkring SAN - vi har fået et fantastisk setup til meget få penge, i forhold til hvad en lignende SAN løsning ville have kostet. Og i vores tilfælde, synes jeg ikke at vi savner funktionalitet - tværtimod!

På sigt vil jeg gerne udvide maskinen med et diskarray mere, fremfor at købe mindre arrays til enkelte maskiner i huset (fx til vores Final Cut klippemaskine og ProTools lydredigerings suiter), og koble det hele sammen med 10GbE iSCSI eller lignende.. til hurtig near-line storage, som automatisk spiller sammen ifht. remote replikering mv.. men det kommer nok på et senere tidspunkt, når behovet for mere (og hurtigere) storage, melder sig.

@Kasper
Tak for svar. Jeg kunne godt tænke mig at se jeres setup.

Hvilke HBA'er bruger I? Er det billige LSI enheder (1068E), Intel SASUC8I/SASMF8I eller hvad? Jeg går ud fra I ikke benytter dyre 3Ware, Areca, Adaptec (skod) eller lignende?

Der er ingen egentligt grund til at vi kører snv_133 fremfor 134 - bør få opgraderet på et tidspunkt, men venter nok til næste egentlige release.

Er der nogen som har et ETA for den? 2010.03 ser ud til at være glemt fra Oracles side, i hvert fald er der intet nyt på den front... kedeligt.

@Nikolaj, vi bruger en LSI 1078 baseret RAID controller, hvor de enkelte diske er eksporterede som RAID0 - controlleren understøtter desværre ikke JBOD, derfor denne løsning. Har testet en masse, og reelt har det ingen betydning for performance - men management mæssigt er det lidt besværligt. Hvis man fx skal udskifte en disk, skal man lave lidt manuelt ifht. at eksportere disken, i stedet for bare at sætte den nye disk i.

Når der på et tidspunkt skal et ekstra array på, kunne jeg godt finde på at lave det om, og udskifte controlleren.

Du er meget velkommen til at kigge forbi, send mig en mail på kasper@copenhagenbombay.com :-)

@Nikolaj, mht. nyt release - jo, lige nu står det vist lidt stille, men jeg tror at et release er på trapperne, omend de nok ikke kalder det 2010.03.

Jeg holdte i øvrigt vejret, da der var snak/rygter om at droppe OpenSolaris, men Oracle har senere meldt ud at de vil fortsætte med udviklingen.

@Kasper

Du er meget velkommen til at kigge forbi, send mig en mail på

Tak for invitationen! ;-)

LSI 1078 baseret RAID controller

Derfor kigger jeg på at bruge en 1068E baseret controller, som f.eks. Intel SASUC8I/SASMF8I (kan flashes med LSI firmware). De er billige, skulle performe rigtig godt, kører JBOD, i f.eks. et Norco 4220.

@Kasper

Nu synes jeg der er lidt forskellige forklaringer i artiklen og i dine egne svar (går ud fra dine kommentarer sikkert er det korrekte)

Men hvis i brguer en enkelt SSD til at placere data hvor der skrives meget er der så ikke en risiko for at i mister data hvis disken dør? Udfra artiklen lyder det som om det er en enkelt X25-E SSD disk uden raid?

Er det en accepteret risiko i har valgt, eller er det fordi jeg ikke forstår hvordan det virker sammen med ZFS?

Med venlig hilsen

Jonas Larsen

@Jonas

Hos os, bruger vi SSDer på to forskellige måder:

Vi har 2 stk. X25-M 160GB i filserveren. Disse to er sat op som L2ARC.

Når data har ligget cachet i RAM i et stykke tid, bliver dataen enten fjernet, eller lagt over i L2ARC'en i stedet, afhængigt af hvor ofte dataen tidligere er blevet læst. L2ARC'en er caching lag mellem diskene og RAM. L2ARC cacher udelukkende læsninger.

Læs evt. mere om L2ARC på http://goo.gl/6p94.

Udover L2ARC, bruger vi en X25-E til ZIL/slog på vores disk-pool. Denne SSD tager sig af sync writes, oftes NFS og iSCSI. Det har ret stor betydning for performance, at der kan blive "læsset" data over på denne disk, midlertidigt - indtil det bliver skrevet videre til de langsommere SATA diske. Hvis du laver en masse sync writes imod de 15 SATA diske vi har til de enkelte servere, ville det sløve hele systemet rigtigt meget. Med en SSD imellem, bliver skrivningerne lagt på X25-E'eren midlertidigt, og skrevet til SATA diskene "ved lejlighed".

Det er korrekt at det er anbefalet at man benytter mirrored ZIL/slog, men med de nyeste OpenSolaris builds, er det muligt at få ens pool op, selv hvis ens log device bliver pillet af. Derfor anser vi det ikke som noget større problem, at vi kun har en enkelt.

@Kasper

Hvilke SATA diske har i købt ind, og hvor har i kigget efter rådgivning? Jeg tænkt på om i har benytte noget lignende: http://www.tomshardware.com/charts/hard-drives,3.html

Umiddelbart var jeg ikke klar over at der fandtes en decideret brugergruppe for OpenSolaris folk her i landet? Fortæl venligst mere :)

http://hub.opensolaris.org/bin/view/User+Group+dosug/

Hov, for de interesserede, er her lidt tal:

Vi har en ARC read cache hit på ca. 80%. Det betyder at 80% af de læsninger serveren håndterer, ligger cachet i RAM. De resterende 20%, bliver hentet på hhv. L2ARC cachen (2x160GB Intel X25-M), og på de langsommere SATA diske.

Langt de fleste læsninger, er altså cachede i en eller anden grad. L2ARC'en hjælper os rigtigt meget på random reads, og ofte ser jeg at SSDerne laver fx flere tusind read IOPS, hvor SATA diskene laver nogle hundrede - hvis L2ARCen ikke havde været der, havde de par tusind IOPS læst fra SATA diskene.

Serveren er på netværket med 4x1GbE, med traditionel link aggregation. Det fungerer OK, og jeg har ved flere lejligheder set serveren maxe de 4GbE ud, når der er rigtigt meget tryk på.

Serveren er på netværket med 4x1GbE, med traditionel link aggregation. Det fungerer OK, og jeg har ved flere lejligheder set serveren maxe de 4GbE ud, når der er rigtigt meget tryk på.

Hvordan opsamler i statistik på brugen af serveren? Nagios?

@Nikolaj,

Hvilke SATA diske har i købt ind, og hvor har i kigget efter rådgivning?

Vi har købt 2TB 7200RPM Hitachi diske. SSD løsningen gør desuden, at vi kan bruge denne "langsommere" type diske, imod fx mindre og hurtigere 10-15K RPM SAS diske - og langt hen ad vejen, få meget høj performance.

Desuden sparer vi penge på strøm, sammenlignet med hvis vi havde valgt hurtigere diske, hvilket fuldstændigt er i Copenhagen Bombays ånd.

Hvordan opsamler i statistik på brugen af serveren? Nagios?

I dag har vi kun noget basal trafikovervågning kørende i Cacti (rrdtool baseret), men på sigt vil jeg gerne have nogle mere avancerede statistikker ud, fx cache hit mv.

Se fx nederst her: http://goo.gl/A7hJ

Overvågning består i dag af mindre hjemmelavede scripts, jeg er så småt gået i gang med at tænke i Nagios baner. Men vi har et meget lille antal servere (ca. 10 stk), hvoraf langt de fleste ikke har brug for decideret overvågning (da de bare er noder, i et cluster til beregning af bl.a. 3D), og enkelte noder godt kan undværes periodisk.

Derfor kigger jeg på at bruge en 1068E baseret controller, som f.eks. Intel SASUC8I/SASMF8I (kan flashes med LSI firmware). De er billige, skulle performe rigtig godt, kører JBOD, i f.eks. et Norco 4220.

Jeg har 2 maskiner med 1068E. De kom med firmware som gav raid mulighed. Hvis jeg ville bruge dem som JBOD, så skulle jeg reflashe med en anden firmware. Det fungerede dog nemt, og i dag kører den JBOD.

Måske 1078 controlleren er på samme måde?

Jeg har 2 maskiner med 1068E. De kom med firmware som gav raid mulighed. Hvis jeg ville bruge dem som JBOD, så skulle jeg reflashe med en anden firmware. Det fungerede dog nemt, og i dag kører den JBOD. Måske 1078 controlleren er på samme måde?

I wish! Vi har haft rigtigt meget bøvl med hardware leverandøren og netop controllerne. Desværre har vi opgivet at få controllerne til at køre JBOD :-(

I wish! Vi har haft rigtigt meget bøvl med hardware leverandøren og netop controllerne. Desværre har vi opgivet at få controllerne til at køre JBOD :-(

Overvejede i ikke at bygge selv, i stedet for at købe hos leverandøren? Hvad hardware om man må spørge? Og hvilken leverandør? Overvejede i Sun hardware på noget tidspunkt? (Deres Sun Fire X4540 Server ser jo dejlig ud)

I wish! Vi har haft rigtigt meget bøvl med hardware leverandøren og netop controllerne. Desværre har vi opgivet at få controllerne til at køre JBOD :-(

Hvem er din hardware leverandør? De 2 maskiner jeg taler om er SuperMicro SuperServer http://supermicro.com/products/system/2U/6026/SYS-6026T-3RF.cfm Jeg synes de laver lækre maskiner hvor man selv skal komme med sine diske. De har også nogle 4U kabinetter, SC847, med skuffer til 24 x 3,5" foran og 12 x 3,5" skuffer i bag. Oven på diskene i bag er der plads til et bundkort. Ialt 36 diske,

Regner dog med at prøve at lave rå netværksprintere uden SAMBA, men direkte til CUPS fra Windows

Det er muligt fra Windows til Linux (direkte til CUPS, uden SAMBA), så mon ikke også det er muligt i OpenSolaris?

Det er muligt fra Windows til Linux (direkte til CUPS, uden SAMBA), så mon ikke også det er muligt i OpenSolaris?

Jo det tror jeg det er. CUPS bliver fremadrettet det eneste printsystem i OpenSolaris (LP droppes).

Kan Samba protokollen levere en båndbredde der kan udnytte alle de fine tiltag?

Hvis ikke kan en Apache server fint udnytte en 1GBit ethernet forbindelse ( med f.eks wget ). Virker selvfølgelig kun den ene vej.

Hvis hastigheden er af betydning, kan man udnytte de mange kerner v.h.a. pbzip2. I mange tilfælde kan bzip2 også give en højere komprimering.

Til folk med ønsker om lignende hastigheder, på hjemme serveren, men uden den helt store pengepung.
Et setup med 3 IntelX25-M i et raid0 software raid kan levere omkring 800 Mbyte/s (read). ( Linux sw-raid). BIOS baseret SW raid må antages at give en tilsvarende hastighed ).

Dette er forudsat at sata-controlleren ( + mainboard)) kan levere denne båndbredde.

En Intel ICH10 ( hedder den vist ) kan godt.

Sæt ikke en fjerde Intel X25-M på, det giver ikke mere båndbredde gennem en normal motherboard controller.

Til folk med ønsker om lignende hastigheder, på hjemme serveren, men uden den helt store pengepung. Et setup med 3 IntelX25-M i et raid0 software raid kan levere omkring 800 Mbyte/s (read). ( Linux sw-raid). BIOS baseret SW raid må antages at give en tilsvarende hastighed ).

Men hvorfor Linux? Det er jo her ZFS skinner - den har ikke write-hole mv. af dårligdomme fra RAID, som ikke er fixet de sidste 30 år (andet end med batteri på controllers, UPS osv.), ligemeget om det er BIOS SW raid, eller dmraid i Linux.
Desuden er RAID0 vældig sårbart, så det forstår jeg ikke.
Hvad er iøvrigt kapaciteten af den server? Det ser ikke ud til at man kan have ret mange af sine DVD film, billeder og CD'er på den før den er fyldt op.

Min hjemmeserver kører med 4 1 TB Samsung (de er hurtigst på SATA området) SATA diske i RAIDZ. Jeg påtænker at stripe endnu et RAIDZ array på.

Jeg vil mene at arkitekturen med L2ARC/ZIL er bedre value for money end at kører rent RAID med SSD, specielt til hjemmeserveren:

http://en.wikipedia.org/wiki/Solid-state_drive#ZFS

800 Mbyte/s (read)

Det er fint, men hvordan får du udnyttet det henover et netværk som kører 1 Gb? Du skal vel op i nærheden af 10 Gb for at kunne overføre 0.8 GB/s - eller er der noget jeg misser?

Linux:

Linux, fordi tallene er kommet til veje v.h.a. Linux.

dmraid:

Et dmraid array kan flyttes til en anden maskine uden problemer. BIOS raid er bundet til maskinen.

Raid sårbarhed:

Hvis det skal virke som cache, er sårbarheden ikke i fokus.

Kapacitet:

Kapacitet vil være 380 til 3160 GB. DVD film skal typisk afspilles med en noget lavere hastighed ( medmindre man spoler hurtigt igennem filmen ) her er hastighed vel ikke så relevant.
Til mit brug "rendering" er det fint med 320 Gb ( af gangen).

800 Mbyte/s via 1GBit/s:

Det er jo ikke al trafik, der skal formidles på een 1Gbit forbindelse. Der er typisk flere samtidige brugere og flere ethernet forbindelser samt lokal aktivitet på maskinen.

I mit tilfælde er der 16 processorer lokalt på maskinen der hiver data ind. I/O er flaskehalsen.

Et dmraid array kan flyttes til en anden maskine uden problemer. BIOS raid er bundet til maskinen.

SW "RAID" i OS er normalt at foretrække fremfor proprietært SW 2RAID" i BIOS. Enig. ZFS gør det bare bedre end dmraid og lvm2 (og er meget simplere at administrere + fleksibelt).

Hvis det skal virke som cache, er sårbarheden ikke i fokus.

Du skrev ikke det var en cache. Hvilken kernel software benytter du i din Linux, som bruger dit array som cache for et back storage?

Det er jo ikke al trafik, der skal formidles på een 1Gbit forbindelse. Der er typisk flere samtidige brugere og flere ethernet forbindelser samt lokal aktivitet på maskinen.

Der er ikke typisk specielt mange særligt effektive PCIe 1 Gb/s forbindelser på et "hjemmeserver" bundkort i den lave ende, som tilbyder 802.3ad/802.1AX-2008.

I mit tilfælde er der 16 processorer lokalt på maskinen der hiver data ind. I/O er flaskehalsen.

Processer eller processorer?

Hvilken kernel software benytter du i din Linux, som bruger dit array som cache for et back storage

Det gør jeg ikke. Jeg skal typisk køre de samme filer igennem mange gange i forskellige konfigurationer. Filerne kopieres manuelt (script) fra et 2TB storage.

Raid'et er en partition. Man kan vel benytte den som en fysisk disk med ZFS?

Processer eller processorer?

Processer og processorer! ( 4 x 4 AMD ).

Det gør jeg ikke. Jeg skal typisk køre de samme filer igennem mange gange i forskellige konfigurationer. Filerne kopieres manuelt (script) fra et 2TB storage.

OKI ;-).

Raid'et er en partition. Man kan vel benytte den som en fysisk disk med ZFS?

Du kan sådan gøre hvad du vil med diskene i ZFS. Det gode her er at der ikke er nogen bunden konfiguration, du skal benytte, eller ikke kan komme ud af (jvf. hardware RAID). ligesom at hvis du har købt en RAID5 controller og vil have RAID60 og det ikke er understøttet, så skal du købe en ny controller. ZFS skal du bare opdatere.

Processer og processorer! ( 4 x 4 AMD ).

Så 4 processorer med 4 kerne i hver? Processer og processorer er ikke det samme.

Jeg har svært ved at se dette falde ind under kategorien:

hjemme serveren

Jeg havde overvejet Linux til min hjemmeserver (faktisk kørte min gamle server SLES), men da jeg lavede den nye, faldt valget altså på OpenSolaris ZFS, da den bare rocks.

Dit setup er sikkert også godt (og det virker som om det spiller max for dig), men noget af det manuelle arbejde med at flytte frem og tilbage til back storage, er det du burde komme ud over med L2ARC/ZIL.

Jeg har svært ved at se dette falde ind under kategorien: hjemme serveren

Det var dig selv, der spurgte ind til mit set-up og brug. Jeg foreslog ikke mit set-up til en typisk hjemme server - kun en delmængde heraf.

Jeg nævnte bare at man kunne få høj båndbredde ( som artiklen omhandler ) med "standard" komponenter. Jeg tænkte specielt, at den øvre grænse på "standard" komponenterne var nyttig information.

Det kan være, at jeg skal eksperimentere lidt med L2ARC/ZIL.

Det var dig selv, der spurgte ind til mit set-up og brug. Jeg foreslog ikke mit set-up til en typisk hjemme server - kun en delmængde heraf. Jeg nævnte bare at man kunne få høj båndbredde ( som artiklen omhandler ) med "standard" komponenter. Jeg tænkte specielt, at den øvre grænse på "standard" komponenterne var nyttig information.

Ahh, OK.
Men med ZFS kan det vel give god mening at sprinte endnu flere diske i stripe (RAID 0) som cache. Jeg har set tal fra den gamle Thumper (Sun Fire X4500), med traditionelle SAS diske, der lander på omkring 1,3-1,4 GB/s (altså uden SSD).

Kan Samba protokollen levere en båndbredde der kan udnytte alle de fine tiltag?

iSCSI kan og er langt at foretrække. Hvis ikke Windows er indblandet kan også NFS 4 bruges (Linux virker vist ikke i NFS 4 endnu - jeg er ikke sikker).

Det kan være, at jeg skal eksperimentere lidt med L2ARC/ZIL.

Jeg synes i hvert fald det spiller.

Det ærgelige er at teknologien er forbeholdt OpenSolaris (selvom det er super godt), og ikke findes til bla. Linux (GPL licensen forhindrer det, men der er altid FUSE, som så dog har lidt begrændninger). xBSD har en port, men jeg er ikke klar over hvor godt den følger med, ligesom Apple droppede det... :-(

Det ærgelige er at teknologien er forbeholdt OpenSolaris (selvom det er super godt), og ikke findes til bla. Linux (GPL licensen forhindrer det, men der er altid FUSE, som så dog har lidt begrændninger). xBSD har en port, men jeg er ikke klar over hvor godt den følger med, ligesom Apple droppede det... :-(

Så vidt jeg husker så er en medvirkende grund til at Linux ikke har ZFS at Linus ikke kan lide det at ZFS sammenblander block level og filsystems level.

Så 4 processorer med 4 kerne i hver? Processer og processorer er ikke det samme

Du har ret. Men føler godt jeg kan tillade mig at omgås betegnelserne lemfældigt.

Tidligere var en CPU ( central processing unit) en styrende funktion i en microprocessor. Efter et stykke tid blev CPU en gængs betegnelse for hele mikroprocessoren.

Med flere kerner per processor og flere processor per computer er betegnelsen heldigvis ved at uddø.

Det er vel også svært at bestemme hvilken af fire CPU'er der er mest central.
:-)

Men med ZFS kan det vel give god mening at sprinte endnu flere diske i stripe (RAID 0) som cache. Jeg har set tal fra den gamle Thumper (Sun Fire X4500), med traditionelle SAS diske, der lander på omkring 1,3-1,4 GB/s (altså uden SSD).

Det kan kun lade sig gøre med PCI-e 8x controllere. Båndbredden på standard sata-controllere er ikke så høj. Flaskehalsen er south-bridge for de hurtigste sata controllere.

Kan Samba protokollen levere en båndbredde der kan udnytte alle de fine tiltag?

Vi har ikke oplevet hastighedsproblemer ved at benytte SMB, det performer langt over forventning. Der er snak om at SMB2 vil øge hastigheden yderligere, men det er endnu ikke implementeret i OpenSolaris' kernel SMB/CIFS.

I øvrigt har vi konstateret at Windows 7 performer langt bedre end Windows XP x64, som vi tidligere har benyttet. Windows 7 kan uden de store problemer, maxe et 1GbE link fuldstændigt ud (selv uden jumboframes), hvor jeg aldrig har set mere end max 50% på XP.

Det er stort set umuligt at sætte præcise tal på hvilken performance man kan få ud af et system som vores - det afhænger 100% af hvordan man arbejder med den pågældende data.

Vi har langt flere reads end writes på vores server, og her hjælper L2ARC cachen os utroligt meget.

Det gør jeg ikke. Jeg skal typisk køre de samme filer igennem mange gange i forskellige konfigurationer. Filerne kopieres manuelt (script) fra et 2TB storage.

Det lyder som en tosset måde at gøre det på, i hvert tilfælde når man sammenligner med hvordan OpenSolaris ville klare opgaven, med L2ARC. Som tidligere nævnt, så prøv at læs dette indlæg: http://goo.gl/6p94

Det kan kun lade sig gøre med PCI-e 8x controllere. Båndbredden på standard sata-controllere er ikke så høj. Flaskehalsen er south-bridge for de hurtigste sata controllere.

Ja men her kan en Intel SASUC8I vel bruges som HBA i JBOD mode til en pris ~ 1.200,-.

Det lyder som en tosset måde at gøre det på, i hvert tilfælde når man sammenligner med hvordan OpenSolaris ville klare opgaven, med L2ARC. Som tidligere nævnt, så prøv at læs dette indlæg: http://goo.gl/6p94

..? Vel ikke mere tosset end at have "levet" med en 50% udnyttelse af en ethernet forbindelse.

Man forfiner vel sine metoder hen ad vejen.

Så vidt jeg husker så er en medvirkende grund til at Linux ikke har ZFS at Linus ikke kan lide det at ZFS sammenblander block level og filsystems level.

Han kan vel ikke bestemme om nogen har lyst til at lave et nyt filsystem der blander disse to lag sammen?
Det er vel GPL der er begrænsningen.

Så vidt jeg husker så er en medvirkende grund til at Linux ikke har ZFS at Linus ikke kan lide det at ZFS sammenblander block level og filsystems level.

Jeg tror du husker forkert, i hvert fald ser det ud til at han rigtig gerne ser ZFS for Linux:

http://lwn.net/Articles/237905/

Vi har ikke oplevet hastighedsproblemer ved at benytte SMB, det performer langt over forventning. Der er snak om at SMB2 vil øge hastigheden yderligere, men det er endnu ikke implementeret i OpenSolaris' kernel SMB/CIFS.

Hvis SMB2 kan øge hastigheden, hvordan kan SMB så være tilfredsstillende?

Med wget eller rcp, får jeg de bedste resultater, d.v.s næsten 100% udnyttelse af en 1Gb. ( rcp er ikke så vellidt - men giver god performance )

Han kan vel ikke bestemme om nogen har lyst til at lave et nyt filsystem der blander disse to lag sammen?

Han kan vel godt bestemme om han vil putte kode ind i hans kerne? Koden kan selvfølgelig leve ved siden af som noget man selv patcher oven på, eller evt. noget som distributionen patcher på for dig.

Det er kun lidt rigtigt at GPL sætter begrænsningen. Godt nok kan man ikke putte opensolaris koden ind i Linux, men der er intet i vejen for at nogen laver en reimplementation.

Hvis SMB2 kan øge hastigheden, hvordan kan SMB så være tilfredsstillende?

Jeg ved ikke hvordan kernel SMB performer hvis vi kommer over de 4x1GbE vi har til rådighed i dag, men det kan være der er noget at hente med SMB2, når man når højere hastigheder. SMB er fint til den båndbredde vi har behov for i dag.

Jeg tror du husker forkert, i hvert fald ser det ud til at han rigtig gerne ser ZFS for Linux:

Det kan godt være at jeg husker forkert, for det ser da ud til at han er positivt indstillet i den email. Dog snakker den kun om relicense og ikke direkte "det vil jeg gerne have".

Han kan vel godt bestemme om han vil putte kode ind i hans kerne? Koden kan selvfølgelig leve ved siden af som noget man selv patcher oven på, eller evt. noget som distributionen patcher på for dig.

Mig bekendt behøver Linus ikke putte kode ind i kernen for at et nyt filsystem kan kører på Linux. Det kan da ske uden om ham. Ligesom vi får drivers og andet udenom ham.

Koden kan selvfølgelig leve ved siden af som noget man selv patcher oven på, eller evt. noget som distributionen patcher på for dig.

Ville der være noget i vejen for at lave ZFS som et kernel module i "restricted" på samme måde som nVidia laver deres drivere?

Ville der være noget i vejen for at lave ZFS som et kernel module i "restricted" på samme måde som nVidia laver deres drivere?

Jeg ved det ikke, men det burde undersøges, for der hvor OpenSolaris her det super fil system, har Linux de super mange gode programmer (bla. VLC, Myth osv. til medie server).

Jeg ved det ikke, men det burde undersøges, for der hvor OpenSolaris her det super fil system, har Linux de super mange gode programmer (bla. VLC, Myth osv. til medie server).

En del af dem kan vel recompileres på OpenSolaris?

Så vidt jeg har hørt får man ikke særlig meget hjælp hvis man får (kerne) problemer med en binary restricted driver loadet. Jeg synes også at fremgangsmåden er forkert. Hvis man alligevel skal kode en driver som bruger Linux driver API, så kan man vel lige så godt gøre det åbent og i GPL så det passer ind i linux kernen.

Jeg tror ikke der er så stor efterspørgsel for at få ZFS til Linux længere, efter btrfs er ved at blive stabilt. Det skulle være inspireret af ZFS, og bliver default filsystem til næste version af Ubuntu og SUSE.

http://en.wikipedia.org/wiki/Btrfs

En del af dem kan vel recompileres på OpenSolaris?

VLC har været forsøgt, og der har været en release af 0.98, men det er noget med at der er problemer med rettigheder og/eller licenser til noget codec stads, det blev i hvert fald fjernet igen. Derfor har man valgt en anden vej i OpenSolaris.

Hvis jeg reimplementere ZFS, så får jeg problemer med patenter og copyrights.

Jeg synes også at fremgangsmåden er forkert. Hvis man alligevel skal kode en driver som bruger Linux driver API, så kan man vel lige så godt gøre det åbent og i GPL så det passer ind i linux kernen.

Naturligvis. Men hvis du ser på hvor langt diverse ZFS-løsninger i GPL er nået, så holder jeg med på restricted support. Det burde være lettere at lave.

Er der nogen der kender til hastigheden i Btrfs?
Jeg anvender i øjeblikket XFS, bla. på grund af hastigheden.

Der er for nyligt lavet en benchmark af forskellige Linux filsystemer her: http://www.phoronix.com/scan.php?page=article&item=linux_2634_fs

Nu er jeg selv skiftet fra ETX3 og andre til rent XFS, netop pga. af hastighed. Jeg har en markant forskel i ydelse om det er ETX3 eller XFS jeg har data liggende på, til XFS' fordel.

Hvis jeg flytter 300GiB data i blandede filer fra en XFS-disk til en anden (ikke bare mellem 2 partitioner på samme disk), så har jeg en gennemsnitlig overførsel i størrelsesordnen 80-90 MiB/s. Og jeg anvender ikke RAID af nogen art, hverken i HW eller SW. Der er tale om gode SATA-diske.

Derfor spør' jeg til ydelse. Og jeg kan ikke nikke genkendende til de resultater Phoronix er nået frem til.

@Jesper

Hvad er hastighedsbegrænsningerne på dine diske? Det er væsentligt at vide, for at se om det er skrive-begrænsningen der sætter ind eller det er filsystemet. Jeg går ud fra det er SATA 2.0 (3.0 Gbit/s), så der ingen begrænsing er her? Hvad er chipsættet?

PS: Phoronix ser også underligt ud i min øjne.

Jeg går ud fra det er SATA 2.0 (3.0 Gbit/s), så der ingen begrænsing er her? Hvad er chipsættet?

SATA-II og AMD 780G (SB700). Der er altså ikke noget super-duper-performance-hardware i og alligevel kan jeg ikke få XFS-ydelsen ned på linie med Phoronix' resultater.

Det er bare gode server-grade diske og en ret standard AMD-løsning. CPU'en er i øvrigt en Athlon X2 5050e.

Da jeg stiftede bekendtskab med XFS første gang lå både EXT3 og ReiserFS så dårligt at de ikke var værd at spilde meget tid på. Desværre kunne Ubuntu 6.06 ikke klare XFS på /boot.

Jeg har en maskine meget lig din AMD Athlon X2 5050e, 8GB RAM og AMD 780G (Gigabyte Micro-ATX bundkort). Den ruller OpenSolaris med ZFS, og har super hastighed, specielt på netværksoverførseler (også SAMBA til Windows XP/Vista/7).
Den er dog opgraderet med Intel PCIe netkort.
Diskene er Samsung F1 1TB.

Jeg synes den tjener udemærket. Den har lige nu 4 diske, men den skal snart flytte til "større lokaler", og jeg overvejer en Norco 4220, og så opgradere processoren henadvejen, måske bundkort og RAM.

Jeg har en maskine meget lig din AMD Athlon X2 5050e, 8GB RAM og AMD 780G (Gigabyte Micro-ATX bundkort). Den ruller OpenSolaris med ZFS, og har super hastighed, specielt på netværksoverførseler (også SAMBA til Windows XP/Vista/7).

Det er din server?

Mit hardware er min arbejdsstation. Men meget pudsigt i grunden. :-)

Min Windows-maskine er kraftigere og min server lidt mindre (med den er også kun mail-/webserver). Jeg har ingen filserver.

Det er din server?

Ja det er min server. Den afløser min QNAP TS-409 Pro Turbo NAS (ARM BusyBox Linux). Den er forbløffende, og lydløs. Min arbejdsstation er en 2 x Quad Xeon 5345, 8 GB FB-RAM (Ubuntu 10.04) og en MacBook Pro 17".

Ja pudsigt :-)

Jeg har kun Windows 7 på mit mediecenter, og derudover har min kone WIndows XP på en DELL bærbar.

Den afløser min QNAP TS-409 Pro Turbo NAS (ARM BusyBox Linux)

Et voldsomt spring - alene 5050e'eren rykker godt ift. en ARM :-)

Dér for jeg har brug for filsystem-ydelsen kan jeg ikke bruge OpenSolaris og dér hvor jeg kan bruge OpenSolaris har jeg ikke brug for filsystem-ydelsen.
Men skulle jeg bruge en filserver, så ville den også være baseret på OpenSolaris. Det har ligget fast lige siden jeg stødte på OpenSolaris for første gang tilbage i 2008.

Min Windows-maskine (XP Pro) bruges kun til spil og der er andre faktorer som tæller - nVida GF GTX275 og Phenom II X2 550 BE med et mindre overclock :-)

Intet mediecenter og ingen filserver. Jeg er kun mig selv.