OpenSolaris 2009.06 är här!

Det är inte någon inbyggd grafik som käkar upp minnet?

Nope inget sådant, tyvärr (har ett PCIe nvidia 7300LE passivt som äter ström helt i onödan istället, yay). Men nu när du säger det så kanske det är så att det äter upp en viss procentandel utav minnet. Tror nog faktiskt att det kan vara orsaken. Ska se om det går att slå av i BIOS. Någon form av "TurboCache"-tjofräs.
Tack!

Alla komponenter är hemma och installerade nu. Har fotat allt (hårdvaruporr ftw!) och satt upp den nya poolen samt "alla" filsystem och satt upp (hyfsat) vettiga ACL-baserade rättigheter på mapparna och filerna. Blev en del (passade på att omorganisera lite) filsystem om man säger så

Ska precis börja föra över all data (3140 GiB). Har testat att föra över 76.5 GiB (min hemmapp, med massa skräp och gamla backuper) vilket tog 1431 sekunder. Vilket ger en genomsnittlig överföringshastighet på måttliga 54,7 MiB/s. Då var det väldigt varierande filstorleker, allt från någon kiB till flera GiB, men främst små filer. Majoriteten av filerna som ska föras över är på ungefär 50-150 MB (10^6) stora. Hoppas att denna storlek går mer effektivt.

Återkommer med bilder på vidundret (jag gillar att ha 17 diskar kopplade till servern, även om 8 av diskarna måste ligga utanför chassit), benchmark och annat ni kan tänkas vilja veta :)¨

Edit: Har insett en fundamental miss med min zfs-layout. Trodde bara att när jag satte upp mitt zfs-filsystem första gången gjort fel med ACL:er. Men icke, efter lite googlande har jag nu upptäckt att om man har följande struktur:

tank/foo      [zfs filsystem]
tank/foo/bar [zfs filsystem]
tank/foo/bar/enFil

Och sätter sharesmb=on eller sharenfs=on på tank/foo så kommer användaren att kunna montera "foo" och se en "mapp" som heter "bar" men icke se "enFil". Hittade ett inlägg på osol:s forum av en utvecklare som sa att det låg på todo listan men inte var prioriterat. Jäkligt kasst tycker jag.

Aja då måste jag göra om till vanliga mappar.. :/

Edit 2: Darren Moffat har börjat jobba på zfs-crypto boot under x86 nu
http://twitter.com/darrenmoffat/status/6271130831

Har börjat överväga att börja köra ECC minnen. Har tittat på att hoppa på amd, ASUS M4A79XTD EVO mb ligger närmast till hands nu. Vill ha ddr3 även om det inte gör nån direkt nytta pga att i framtiden kunna switcha minnen mellan andra burkar. Hursomhelst verkar det ju vara hyggligt svårt att få tag på obuffrade ECC minnen!? Kollar man prisjakt dyker endast 2 val upp... Kör man ddr2 får man ju fler men undviker gärna ett ddr2 mb. Det har ju varit lite snack om ECC här på sistone, är det fler som hoppat på? Isf ddr2 eller ddr3 (eller äldre)? Helst skulle man ju vilja ha 4GB mackor men det verkar inte finnas. Finns ett 2x4GB kit på dustin för 2700, tyvärr ECC/REG... Några tips?

Är nära att beställa men är ändå inte riktigt säker på nyttan med det hela om man ser till helheten. Som någon påpekade nånstans så är man ju förmodligen inte ECC skyddad hela vägen via bussar osv ändå pss på en server... Undrade även själv tills alldeles nyligen hur det var med cpu cachar på en vanlig desktop cpu men en snabb googling visade att iaf gamla hederliga Athlon 64 x2 verkar köra ECC på l1 och l2 cacharna.
Sen är det ju lite frågetecken om ECC supporten, hur det hanteras av Solaris tillsammans med BIOS. ASUS kortet har iaf några BIOS inställningar relaterat till ECC, gigabytekorten jag kollat nämner ingenting. Någon nämde att vissa MB:s stämplas som "ECC optional" och det då kunde betyda att den kan köra med ECC minnen utan ECC funktionalitet typ... Man vill ju dessutom inte att BIOS ska sköta allting själv utan man vill ha varningar i Solaris om ECC fel inträffar. Svårt att hitta någon som delar med sig av praktiska erfarenheter och det kommer förmodligen bli svårt att verifiera att ECC verkligen funkar. Men man får ju en anledning att vara glad om det rapporteras fel i framtiden...

Enligt http://developmentonsolaris.wordpress.com/2009/03/06/how-to-m... kan man se att scrubbern går, men den verkar ju gå oavsett ECC så det är inte mycket till hjälp. Kollar man källkoden kör scrubbern enbart för att säkerställa att allt minne accessas regelbundet så att ECC fel kan rätas till innan det blir fler.

Såg någon snubbe i nån tråd som lyst med en "tungsten lamp" (vad nu det är) på minnena för att sakta hetta upp dem för att kunna konstatera att ECC fel rapporterades av kerneln (minns dock inte om det var OSOL eller Linux), men det känns som att det är att gå lite långt ...

Men som sagt, det är ju konstaterat att bitflips med största sannolikhet sker och skriver man skit till zfs så får man ju skit tillbaks. Och sen så är det ju så kul att få hem nya grejjer så det blir nog ett inköp ändå, även om ekonomiavdelningen får svårt att räkna hem investeringen

EDIT: För 351 euro kan man beställa 2st 4GB unbuffered ECC stickor direkt från crucial (fri frakt och man fick hjälp att välja kompatibelt minne utifrån MB, alltid nåt). Får nog bli 2GB stickor...

Några anledningar kan ju vara mer finmaskig kontroll över snapshots, quotas, reservations osv som man kan sätta i zfs. dataset är ju så lättviktiga så man kan släppa det gamla filsystemstänket i många lägen.

zfs dataset går ju fint att använda, dock är det väl ett par detaljer med utdelning som inte funkar tillfredställande (har inte sett detaljerna på buggrapporterna osv om det ska implementeras framöver eller inte). Men man har ju användning av zfs i andra fall än för cifs/nfs utdelning.
Kolla här för lite info om hur det funkar (är tänkt att funka?) med shares och child datasets för cifs resp nfs: http://blogs.sun.com/dougm/, t.ex. stycket "SMB shares are resource name based while NFS shares are path based"
Det är väl det som är problemet antar jag och som förhoppningsvis ändras i framtiden?
Samba funkar fint om man delar ut topp-nivån och det är väl så man förväntar sig att det ska funka antar jag.

Edit: @Saddam: En annan fråga, har för mig jag läste att du hade nåt antec p18x chassi och skulle bygga in 8-9 diskar? Körde du med nån typ coolermaster 4-in-3 modul eller nån annan lösning för att få in så mycket disk?

Ok, men dom 3 i toppen då, hur har du satt dom? I nån 5 1/4"->3 1/2" adapter för diskar?

Ang zfs, om man kollar vad som delades ut:

tank/foo [zfs filsystem]
tank/foo/bar [zfs filsystem]
tank/foo/bar/enFil

Det var toppnivån tank/foo som delades ut med sharesmb=on.
tank/foo/bar är ju ett dataset under tank/foo (dvs kan ses som ett eget filsystem) och delas då inte ut så den går att nå som en underkatalog från klienten sett.

Denna får en egen share enl. infon i bloggen jag länkade till. Mappar man upp tank/foo på en klient syns alltså bara att det finns en katalog som heter tank/foo/bar, däremot är den ju tom just för att den inte är utdelad som man förväntar sig.
Kör man samba så blir detta dock helt transparent, samba bryr sig inte om filsystemsgränser oavsett om du kör ufs eller zfs. Delar jag ut tank/foo så ser jag allt därunder som förväntat i detta fall.

Du kan inte göra snapshots på en finare nivå än datasets. Detsamma gäller properties, dom sätter du på individuella dataset. Därav smutt att kunna göra dataset istf kataloger där det passar.

Det tar ju ett tag att vänja sig av med gamla tankebanor när man snackar zfs kontra traditionell partitionering men när man väl lyckas med det så hittar man fördelar (för det mesta...)

Bara det att zfs jobbar med properties är ju omåttligt skönt i vissa lägen. T.ex. när man flyttar disk mellan maskiner. Man behöver inte bry sig om diskaddresser, vfstabs, dfstabs etc. Bara flytta över alla diskar i poolen och boota...

Varning: Långt inlägg.
Finns en fråga till bzzz längst ner, så läs det i alla fall bzzz är du snäll

saddam:
Länk till tråden om cifs/nfs och sub-filsystems problemet: http://opensolaris.org/jive/thread.jspa?messageID=434581&tsta...

Strukturen såg ut så här (allt zfs filsystem):

# zfs list
tank                                707M  8.01T  49.4K  /tank
tank/backup                         267K  8.01T  49.4K  /tank/backup
tank/backup/crashplan              42.6K  8.01T  42.6K  /tank/backup/crashplan
tank/backup/marvin                 87.5K  8.01T  44.9K  /tank/backup/marvin
tank/backup/marvin/tm              42.6K  8.01T  42.6K  /tank/backup/marvin/tm       // För Time Machine
tank/backup/zarquon                87.5K  8.01T  44.9K  /tank/backup/zarquon
tank/backup/zarquon/tm             42.6K  8.01T  42.6K  /tank/backup/zarquon/tm      // För Time Machine

tank/home                           132K  8.01T  47.1K  /tank/home
tank/home/[users]                  42.6K  8.01T  42.6K  /tank/home/...

tank/storage                        895K  8.01T  58.3K  /tank/storage
tank/storage/applications           267K  8.01T  53.9K  /tank/storage/applications
tank/storage/applications/bsd      42.6K  8.01T  42.6K  /tank/storage/applications/bsd
tank/storage/applications/linux    42.6K  8.01T  42.6K  /tank/storage/applications/linux
tank/storage/applications/mac      42.6K  8.01T  42.6K  /tank/storage/applications/mac
tank/storage/applications/solaris  42.6K  8.01T  42.6K  /tank/storage/applications/solaris
tank/storage/applications/windows  42.6K  8.01T  42.6K  /tank/storage/applications/windows
tank/storage/games                  132K  8.01T  47.1K  /tank/storage/games
tank/storage/games/mac             42.6K  8.01T  42.6K  /tank/storage/games/mac
tank/storage/games/windows         42.6K  8.01T  42.6K  /tank/storage/games/windows
tank/storage/misc                  42.6K  8.01T  42.6K  /tank/storage/misc
tank/storage/movies                42.6K  8.01T  42.6K  /tank/storage/movies
tank/storage/music                 42.6K  8.01T  42.6K  /tank/storage/music
tank/storage/os                     267K  8.01T  53.9K  /tank/storage/os
tank/storage/os/bsd                42.6K  8.01T  42.6K  /tank/storage/os/bsd
tank/storage/os/linux              42.6K  8.01T  42.6K  /tank/storage/os/linux
tank/storage/os/mac                42.6K  8.01T  42.6K  /tank/storage/os/mac
tank/storage/os/solaris            42.6K  8.01T  42.6K  /tank/storage/os/solaris
tank/storage/os/windows            42.6K  8.01T  42.6K  /tank/storage/os/windows
tank/storage/series                42.6K  8.01T  42.6K  /tank/storage/series

Men jag kommer att vara tvungen att ta bort alla sub-filsystem under tank/storage då jag bara vill ha en enda utdelning som jag måste montera och ersätta dem med vanliga mappar. Anledningen till att jag vill ha varje subgrupp som ett eget filsystem är för att ha möjlighet att sätta specifika egenskaper på dem beroende på deras uppgift. Samt att lätt kunna se hur mycket disk de nyttja då så klart. Skyddar dessutom mot oavsiktliga "rm -fr /tank/storage/movies" incidenter

En nackdel med att ha sub-filsystem är att mv och cp mellan två zfs-filsystem (annat sub eller en sub:s förälder) är att det är som att flytta/kopiera mellan två vanliga partitioner. Kommer upp i ungefär 125 MiB/s mellan zfs-filsystem (inom samma vdev).

Det kommer nog att tillkomma ett sub-filsystem för virtuella maskiner också. Men först efter att jag installerat 2009.06.

Följande switchar har jag använt vid skapandet av:

För tank/home och tank/backup
* compression=on                // Sätter på compression, med algoritmen lzjb 
* aclinherit=passthrough        // Gör så att ACL:erna ärvs av alla filer
* aclmode=passthrough           // Gör också något så att ACL:erna ärvs ordentligt

För tank/storage, tank/backup/crashplan och tank/backup/*/tm:
* casesensitivity=mixed         // Bra förklaring(*)
* aclinherit=passthrough        // Se ovan
* aclmode=passthrough           // Se ovan

(*)Av saddam: "Unix skiljer på stora/små bokstäver: foo, FOO, FoO - är tre olika filer. Windowsklienten skiljer inte, och listar endast en fil. Detta property tvingar Windows skilja på små/stora bokstäver, och visar nu alla tre filerna".

En annan sak jag precis lärde mig är att ifall man ska köra med Mac-klienter (och säkerligen andra) mot osol+zfs så är det rekommenderat att sätta på "normalization" (måste göras vid zfs create). Vilken normalization man väljer spelar ingen roll, bara man väljer en. Att sätta till "formD" verkar dock vara "rekommenderat". Detta gäller om man aktiverar "utf8only" egenskapen.
http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg28...

Sammanfattning av "utf8only" av saddam: "utf8only: Windowsklienten kan inte lista filnamn med konstiga tecken. Detta property förbjuder alla konstiga filnamn i zpoolen".

Mina ACL:er ser ut på följande vis (en tabell över vad alla flaggor finns i Solaris ZFS Admin Guide, pdf:en, sidan 200-201):

Endast tillåta läsning (alla)
/usr/sun/bin/chmod A=\
owner@:r-x---aAR-c--s:-d-----:allow,\            // Tillåter endast att visa mappens* innehåll samt dess attribut
owner@:r-----aAR-c--s:f------:allow,\            // Tillåter endast att läsa filen** samt dess attribut
group@:r-x---aAR-c---:-d-----:allow,\            // Samma som ovan (mapp)
group@:r-----aAR-c---:f------:allow,\            // Samma som ovan (fil)
everyone@:r-x---aAR-c---:-d-----:allow,\         // Samma som ovan (mapp)
everyone@:r-----aAR-c---:f------:allow \         // Samma som ovan (fil)
/tank/{storage,storage/applications,\
storage/games,storage/os,backup,home}

*: Det är [...]:-d-----:[...] som säger att det är mappar som ärver denna regeln.
**: Det är [...]:f------:[...] som säger att det endast är filer som ärver denna regeln.

Allt utom ~"farligt" (tror jag. Alla, förutom ägare som tillåts allt):
/usr/sun/bin/chmod A=\
owner@:rwxpdDaARWcCos:-d-----:allow,\            // Tillåt allt för ägaren av mappen
owner@:rw-pdDaARWcCos:f------:allow,\            // Tillåt allt för ägaren av filen
group@:rwxpdDaARWc---:-d-----:allow,\            // Tillåt allt utom att ändra ACL, ägare och synkronisera för gruppmedlemmar av mappen
group@:rw-pdDaARWc---:f------:allow,\            // Tillåt allt utom att ändra ACL, ägare och synkronisera för gruppmedlemmar av filen
everyone@:rwxpdDaARWc---:-d-----:allow,\         // Samma som för grupp (mapp)
everyone@:rw-pdDaARWc---:f------:allow \         // Samma som för grupp (fil)
/tank/storage/{misc,movies,series,music,\
games/windows,games/mac,applications/mac,\
applications/bsd,applications/linux,\
applications/windows,applications/solaris,\
os/mac,os/windows,os/linux,os/solaris,os/bsd}

Läsa (alla) och skriva (ägare och grupp):
/usr/sun/bin/chmod A=\
owner@:rwxpdDaARWcCos:-d-----:allow,\            // Tillåt allt för ägaren av mappen
owner@:rw-pdDaARWcCos:f------:allow,\            // Tillåt allt för ägaren av filen
group@:rwxpdDaARWc---:-d-----:allow,\            // Tillåt allt utom att ändra ACL, ägare och synkronisera för gruppmedlemmar av mappen
group@:rw-pdDaARWc---:f------:allow,\            // Tillåt allt utom att ändra ACL, ägare och synkronisera för gruppmedlemmar av filen
everyone@:r-x---aAR-c---:-d-----:allow,\         // Tillåt alla andra att visa mappens innehåll samt dess attribut
everyone@:r-----aAR-c---:f------:allow \         // Tillåt alla andra att läsa filen samt dess attribut
/tank/{backup/marvin,backup/marvin/tm,\
backup/zarquon,backup/zarquon/tm}

Edit: Uppdaterade nedanstående 2009-12-04:
Allt (ägare), läsa (grupp) och inget (alla andra):
chmod A=\
owner@:rwxpdDaARWcCos:-d-----:allow,\            // Tillåt allt för ägaren av mappen
owner@:rw-pdDaARWcCos:f------:allow,\            // Tillåt allt för ägaren av filen
group@:r-x---a-R-c---:-d-----:allow,\            // Tillåt grupp att läsa
group@:r-----a-R-c---:f------:allow,\            // Tillåt grupp att läsa
everyone@:------a-R-c---:-d-----:allow \         // Tillåt alla andra att se mappen och dess attribut, utökade attribut och ACL.
/tank/{home/*,backup/crashplan}

De är inte perfekta men jag tror att de duger för tillfället i alla fall.

Sen så fick jag ut i genomsnitt lite mer än 100 MiB/s mellan zpool:erna. Båda anslutna till samma dator, nya poolen till det nya SAS-kortet (AOC-USAS-L8i, som för övrigt stödjer fördröjd spin-up och S.M.A.R.T. om någon undrar) och gamla poolen till den integrerade kontrollern samt två på ett kontrollerkort på PCI-bussen. När alla filer är på plats (är ungefär 1.5 TiB kvar som nu måste flyttas från sub-filsystem till vanliga mappar) ska jag testa att föra över över nätverket samt bencha. Återkommer med resultat samt även bilder så klart!

bzzz:
Även jag kör just nu 9 diskar i mitt Antec P180 chassi. 4 diskar där nere, 4 diskar där uppe (i 4-in-3 adapter) samt en i mitten. Skall expandera till två diskar i mitten. Funkar fin fint. Dock har jag fel typ av fläkt i 4-in-3 adaptern så de diskarna blir just nu lite för varma. Ska dock byta till en med lite mer flås.

Vilken version av zfs kör du? För precis det du skriver om samba (zfs property sharesmb tänker du då på antar jag?) fungerar inte för mig. Jag kör ZFSv14, b104, kanske är för gammalt?

Om jag gör

# zfs set sharesmb=on tank/storage
# zfs set sharesmb=off tank/storage/series

Och därefter monterar den cifs/smb-utdelade "enheten" "tank_storage" så ser jag en "mapp" som heter "series". Klickar jag på den så är den tom. Klickar jag däremot på en annan vanlig mapp (med samma ACL och ägare) så kommer filer och under-mappar upp.

Tack båda för infon om diskplaceringen, tänkte köpa ett p183 och funderade mest på om en 4-in-3 modul skulle passa, det kan ju vara lite kinkigt med chassin där man inte skruvar fast 5 1/4" enheterna (hade för mig att det var några skenor man skruvade fast i resp. enhet för att sen skjuta in i chassit.)

Ang zfs igen så kör jag ren user-space samba, dvs inte solaris kernel cifs som man styr mha zfs properties osv som ni gör. Det var enklast då jag bara flyttade över konfigen rakt av ifrån min gamla linux-burk, orkade inte försöka lära mig acl syntax osv för CIFS. Kändes som att man inte kunde konfa den riktigt lika utförligt heller, t.ex. speca subnät man vill dela ut till osv. Därav spelar ju inte min zfs version ngn roll heller, men kör nu den som ingår i 2009.06 vad nu det är.
Vet inte om det skiljer något i prestanda osv, googlade lite på detta vid tiden då jag satte upp det och då var det ingen större skillnad iaf så jag såg ingen anledning att byta till solaris cifs.

Just det där som du beskriver finns ju beskrivet i bloggen jag länkade till, ett utdrag:

Blir det inte nåt liknande om du ifrån en windows klient kör net view \\opensolaris-server dvs dina datasets hamnar som egna shares?
Personligen skulle jag nog isf försöka konsolidera ihop dataseten till ett par toppnivåer som man kan dela ut, t.ex. tank/storage/applications, tank/storage/games osv. Är du nöjd med din zfs layout känns det ju dumt att behöva överge den helt pga detta och då torska individuella quotas/reservations/snapshots, send/receive möjligheter etc. Alternativet är väl ren samba men då torskar du ju ACL:erna.

Samba fanns färdigpaketerat i contrib förresten så man behövde inte göra det själv.

EDIT: Såg att du i din sista post ändrade properties så att du satte sharesmb=off på undernivån, vet inte om jag missförstog frågan. Men i det fallet bör du ju alltså bara få en share för toppnivån.

Annars verkar det av bloggen att döma funka så att sharesmb=on körs rekursivt på alla dataset men att det som sagt blir separata shares vilket förmodligen inte alls är vad man tänkt sig. När jag tänker efter verkar det rent utav korkat fast jag är trött och kanske den som är korkad just nu

saddam: Har uppdaterat med kommentarer efter varje rad. Tror faktiskt jag lärde mig lite mer ACL nu tack vare dig
Sen är sidorna 200 och 201 i Solaris ZFS Administration Guide guld värda! De är nämligen en tabell över privilegierna. Både de långa namnen och de kompakta (som jag använt i mitt inlägg).

bzzz: Jo jag får flera utdelade datasets som jag kan montera. Det skulle egentligen fungera att köra på ett par toppnivåer som du säger (t/s/applications, t/s/games, osv.). Om det inte vore för att jag har flera system som är konfigurerade för att bara montera en share och sedan ha åtkomst till allt, dessa system orkar jag inte konfigurerar om så jag överger nog detta (tyvärr) och går tillbaka till vanliga mappar för tank/storage/* delen

Tror inte jag orkar sätta upp SMB i user-space heller. Jag är som Haskell, lazy
Får väll vara som det är. Aja bara 1,44 TiB kvar... Borde ta typ 3 timmar.

Sen ska jag installera osol 2009.06 på en mirror bestående av två 1 TB WD GP diskar (som tidigare användes i förra zpoolen), det blir nog roligare än att flytta filer.

Testade precis att föra över en lite större fil (7.52 GB). Då gick det i ~50 MiB/s. Gjorde så att jag började föra över ytterligare en fil till en annan disk på min Mac Pro och då gick överförningen upp i totalt ~70 MiB/s. Förde jag över ytterligare en fil till ytterligare en disk så gick överförningen upp i ~90 MiB/s. Så det verkar helt klart som att det är disken i min Mac Pro som begränsar. vdev:en

Setup:
Mac Pro som körde OS X 10.6.2. 2 st 320 GB WD Blue diskar samt en 250 GB Samsung ifrån tidigt 2007.

Ska byta ut hårddiskarna i min Mac Pro till diskar ifrån förra versionen av filservern. Så det blir två 500 GB WD Black (för OS som förhoppningsvis kan öka överförningshastigheten något) samt två 1 TB WD GP diskar.

En annan sak jag precis lärde mig är att ifall man ska köra med Mac-klienter (och säkerligen andra) mot osol+zfs så är det rekommenderat att sätta på "normalization" (måste göras vid zfs create). Vilken normalization man väljer spelar ingen roll, bara man väljer en. Att sätta till "formD" verkar dock vara "rekommenderat". Detta gäller om man aktiverar "utf8only" egenskapen.
http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg28...

Edit:
Benchmark med nya vdev:en:

Using uid:0, gid:0.
Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Version 1.03b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
fs          143160M           237914  52 121324  32           306157  37 600.8   2
fs,143160M,,,237914,52,121324,32,,,306157,37,600.8,2,,,,,,,,,,,,,
root@Zaphod[16:40] / # echo "fs,143160M,,,237914,52,121324,32,,,30

Vilket är ungefär dubbla prestandan jämtemot förra

saddam: Har lagt till det du skrev om casesensitivity och utf8only i min "überpost"

Jag behöver också hjälp att tolka bonnie++ resultatet, allt jag kan uttyda av det och det gamla är att prestandan fördubblats

Jag vill ha home på mitt raid eftersom jag då kan byta ut os:et hur som och ändå ha kvar just home. Inte så bekymrad över fragmentering som du verkar var.

Håller med om att det nog är snyggare att ha tank monterat i /mnt. Inte så svårt att ändra. Kanske jag gör nu efter att jag installera osol 2009.06.

Gällande sub-filsystem och smb/cifs kom vi fram till att det inte funkar på det vis jag/vi vill. Det krävs i dagsläget mappar. Tyvärr. Men problemet finns på utvecklarnas att-göra lista (har dock ingen bugg-id åt er) så jag har bara satt mountpoint till none på alla mina sub-filsystem som jag nu inte använder. Kommer nog dock att förstöra dem och skapa nya (med utf8only och normalization påslagna) när detta är implementerat.

Jag har naturligtvis hembiblioteken (eller kanske rättare sagt hemfilsystemen) lagrade på min raidz2. Tanken är att allt jag sparar ska vara något så när skyddat.. Hembiblioteken är också de enda filsystemen jag regelbundet tar backup på.

Systemdisken vill jag använda just som systemdisk och inget annat. Helst skulle jag vilja få in systemet på en liten och billig SSD.

Fragmentering bryr jag mig inte om öht.

saddam: För mina ACL:er ärvs av alla mappar och ger även en bättre kontroll. Dessutom var det roligt och lärorikt att sätta upp dem

Har lagt upp lite bilder på hur det såg och ser ut.
http://gallery.me.com/acedercrantz#100024&bgcolor=black&view=...

"pkg -R /mnt install entire@0.5.11-0.xxx" tar låång tid :/

lol, pun intended?

För att fylla ut med iaf lite i härheten av OT :

saddam, /mnt brukar mest användas för temporära mounts så vill man ha stilpoäng bör man hitta på en egen mountpoint
Håller dock med om att det inte alltid blir så snyggt med poolen monterad under /. Det går ju dock att flytta runt som man vill och vill man inte montera själva poolen (kanske bara dataset som ska mountas under lite olika kataloger) så kan man ju alltid sätta mountpoint=none.
Och +1 på imponerande kabeltattning!

Undrar jag med

Kan säga att detta är första gången jag tagit mig ork och tid att dra kablarna ordentligt. Allt som allt tog det ett flertal timmar att få de att ligga som de gör nu. Alla kablar ligger i princip i en hög under mitten-enheten (den som rymmer två diskar). Har skruvat av den (värdelösa) lilla lådan som sitter på baksidan av den så nu rymmer det utrymme hur mycket kabel som helst. Tänker dock inte skruva upp för att ta kort på hur det ser ut, vill inte behöva dra om kablar igen :). Inte några konstigheter egentligen. Lägg några timmar på att dra kablar och du kommer få lika bra/bättre resultat.

Kul att ni gillade kabeldragningarna i alla fall. Gör att timmarna känns än mer vettigt investerade!

Har insett en miss med mina ACL:er. Jag ger även grupp skrivrättigheter i hemkataloger. Bad. Fixat i min "überpost". Kör nu rpool på en mirror och har sett till att fixa nästan alla initiella problem jag stötte på. Dels var min (gamla!) zsh konfig inte helt kompatibel med osol 2009.06 (b125, som väll egentligen är 2010.02 preview?) samt att det tog en stund att gå igång samba/cifs (behövde tydligen installera två till paket än vad som kom med som standard..). Nu har jag bara problemet att jag inte kan vnc:a till servern. Tror dock inte det är något jag tänker prioritera att försöka fixa.

Mina erfarenheter av osol:s gui (dessa få dagar) är att det inte gör som jag vill och att det hindrar mig från att göra avsiktliga saker. För att ta ett exempel, lägga till användare i grupper verkar inte gui:et tillåta mig att göra. Lägger till några användare i en grupp och klickar Ok i alla fönster. Har användaren lagts till? Nix. Tacka vet jag "(user|group)(add|mod|del)"

Ska nog ta att installera VirtualBox och smartmontools istället.

Är det någon som provat EON förresten?
http://eonstorage.blogspot.com/

Verkar intressant tycker jag!

Eon med Napp-it är verkligen intressant om man behovet bara är att serva filer.

Tyvärr bygger Eon på SXCE och OpenSolaris Indiana (i det skick det är nu) är inte en bra plattform att porta till.

@rastersize
+1 för kabeldragningen! Jag har samma chassi men jag fattar inte hur du lyckats få till det så bra!

EDIT: GUI:t i OSOL är skräp! Kör med terminalen så blir det mycket enklare!

pr0xy: Tack
Många timmars jobb säger jag bara, så sätt igång själv och upp med bilder sen.
Det hjälpte också att strömkablarna ifrån nätagget var lagom långa mellan alla kontakter. Även om de var anpassade för att komma ovanifrån och inte underifrån som jag var tvungen att dra de, nätaggregatet sitter ju i botten. Var tvungen att snurra dem.

Japp, kör terminal rakt igenom. Tänkte att jag kunde testa att sätta upp basic-sakerna via GUI:et, men det gick ju inget vidare. Hade dock velat komma åt GUI:et, via VNC, för att ha möjlighet att konfigurera CrashPlan lite lättare. Men har hittat en guide för hur man kan köra en headless CrashPlan server och ansluta med klienten på sin egna dator för att konfigurera servern.

saddam: Riktigt roligt att du tycker jag gjort en sådan bra kabeldragning. Gör mig som sagt glad och stolt
Får se med det där om att göra guide hur man bör dra kablarna. Måste ju fixa en hemsida också i sådana fall.
Blir dock inte nu, har tenta snart... :/

Eftersom jag hittat hur jag kan administrera CrashPlan med hjälp av en ssh-tunnel så tänker jag inte lägga någon mer energi på att få VNC att fungera. Sen så kör jag Mac OS X och vill inte köra SunRay emulatorn innuti VMWare. Inte så viktigt som sagt. Terminal vinner alla dagar emot GUI

Det problem som jookeer uppmärksammade oss om för Linux, gällande Western Digital GP diskarna, verkar tyvärr även vara ett problem under osol :/
Mina diskar har kommit upp i 1800-2050 i Load_Cycle_Coun (LCC). Inte så najs, eftersom de endast är specade för 300000 LCCs. Det verkar ticka upp en LCC var annan minut, dock inte alltid ibland tar det längre tid. Vilket ger oss (worst case):
300000 * 2 / 60 / 24 = ~416 dagar

Således borde en WD GP disk som är på 24/7 dö/må dåligt efter lite mer än ett år. Tur att garantin finns kvar, men jobbigt om flera diskar dör samtidigt!
Ska fundera på hur jag tänker göra. Om man antingen ska ta kontakt med inköpsställenas support och fråga dem om de vill byta ut diskarna, en och en (så att jag kan återbygga raid:et efter varje). Eller om man ska byta ut diskarna en efter en under årets lopp. Vilket jag ändå nog hade tänkt göra för att inte en dag stå med ett raid utan ledigt utrymme och behöva spendera en vecka eller två med att installera nya diskar varje dag..
Att utnyttja sin ångerrätt känns inte vidare bra (det är på sätt och vis inte diskarnas fel att operativsystemet frågar dem hela tiden) eller lätt, måste ju på något sätt ha kvar all min data.

Kanske skicka in en bugg-rapport till osol-folket?