:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_icc():strip_exif()/u/44267/wap11.jpg?f=community)
:strip_icc():strip_exif()/u/105956/lill.jpg?f=community)
:strip_icc():strip_exif()/u/48952/Ultraman-60x60-Ray-Animated.jpg?f=community)
Wat heeft dat met ZFS te maken?:
Hoe krijg je het voor elkaar in OpenIndiana dat een USB disk auto mount...iemand
Als je stil blijft staan, komt de hoek wel naar jou toe.
Ultraman heeft eigenlijk wel gelijk ja... Dus maar even:
Hoe krijg je het voor elkaar in OpenIndiana dat een USB disk auto mount...iemand
offtopic:
maar ik was benieuwd geworden en heb het dus even uitgezocht. Het is eigenlijk heel simpel:
# svcadm enable hotplug
maar ik was benieuwd geworden en heb het dus even uitgezocht. Het is eigenlijk heel simpel:
# svcadm enable hotplug
Okee dan toch nog maar even ontopic: hmm nee ik heb eigenlijk toch niks meer te vertellen
Oh wacht ik heb nog wel een interessante vraag. Heeft iemand al ZFS in combinatie met compressie gebruikt? Dat is wel iets wat ik waarschijnlijk wil gaan testen, misschien heeft er al iemand ervaring?
Verwijderd
* veel:
[...]
Wat heeft dat met ZFS te maken?
[ Voor 51% gewijzigd door Verwijderd op 19-05-2011 09:05 ]
Het was te moeilijk om de inkopper niet te doen:
[...]
Goh wat flauw. . Dat is de 2e x
Sorry!Ik gebruik het op een paar filesystems onder mijn FreeBSD 8.2 test installatie, op zaken waarvan ik vooraf wist dat het best wel effectief zou zijn. Dus dingen waar data in zit die goed comprimeert. Zoals logfiles, source code en, weliswaar in mindere mate, tijdelijke files.
Ik gebruik dus compressie op /var/log, /usr/ports (niet de onderliggende distfiles en packages, dat zijn aparte filesystems zonder compressie), /tmp en /var/tmp. Hierop heb ik de lichte "lzjb" compressie aan staan.
Maar ik heb helaas niets qua cijfers of benchmarks voor je.
Wel nog ervaring van vroeger toen ik met Reiser4 speelde, welke ook transparante compressie kon doen. Dat heb ik toen getest en dat leverde een aardige boost op in de meeste gevallen. Alleen kreeg de CPU het iets drukker, maar dat kon mijn AthlonXP destijds wel aan.
Als je stil blijft staan, komt de hoek wel naar jou toe.
Verwijderd
BEDANKT !! ben er 2 dagen mee bezig geweest en als je googled op mount usb openindiana ofzo kom je echt niet uit op het woord HOTPLUG:
[...]
Ultraman heeft eigenlijk wel gelijk ja... Dus maar evenofftopic:
maar ik was benieuwd geworden en heb het dus even uitgezocht. Het is eigenlijk heel simpel:
# svcadm enable hotplug
uiteindelijk was het # svcadm enable svc:/system/hotplug:default
het feit dat ik teste met een kingston datatraveller, de enige USB stick die (achteraf) bekend staat niet te werken in dit systeem hielp niet mee.
@ultraman.. ook bedankt, er zit nu een flinke barst in mijn iPad
[ Voor 11% gewijzigd door Verwijderd op 19-05-2011 09:35 ]
Op zich logisch dat je niet alles comprimeert, veel binaries (muziek, films) zullen niet veel verder gecomprimeerd kunnen worden. Hier wordt trouwens een interessante claim gemaakt:
Maar dat lijkt me inderdaad afhankelijk van de compressie ratio. Kan je dit voor jouw zpool checken? Ben wel benieuwd:
Overigens, deduplication lijkt minder interessant voor thuisgebruik, maar wellicht beter toepasbaar in multi-user omgevingen.
Graag gedaan, mooi dat je het gevonden hebt
Bij mij was "# svcadm enable hotplug" voldoende. Je kan trouwens met "# cfgadm" de devices bekijken.
[ Voor 2% gewijzigd door Micr0mega op 19-05-2011 11:31 . Reden: cfgadm ]
Hallo allemaal,
Even een vraagje voor de ZFS veteranen
Algemene informatie
Ik heb onderstaande configuratie:
Nu loopt dit al een tijdje op Debian met een mdadm configuratie (daarop LVM+XFS)
Ik loop echter tegen een enorm hoog fragmentatie probleem aan (de machine word door meerdere gebruikt, vooral torrents en rtorrent werkt niet lekker mee).
Ik was al van plan te switchen naar ZFS toen ik de hardware binnen had maar ivm uitbreiden van de array heb ik dit niet gedaan, nu wil ik aankomende week toch switchen naar FreeBSD 8.2 met ZFS.
Vraag(en)
- Ik had gelezen dat 4 disks een performance verlies geeft (tegenover 3, 5 of 9 disks) ik ben dus van plan een extra disk aan te schaffen zodat het een raidz word met 5 disks, goed idee ?
- Ik was ook van plan om 8 GB ram bij te prikken voor ZFS, is dit nodig / wenselijk ?
- Performance technisch, wat ik reeel om te verwachtten ? momenteel is mijn lees en schrijfsnelheid vrij laag imo (rond de 50MB) kan dit met ZFS hoger worden ? (ik zal zowizo de 4k sectoren etc goed zetten in de config, dit moet ik nog even uitzoeken / lezen nav eerdere links in deze thread
- Gezien het een gezamelijke bak is (sort of) wil ik ook graag dedup gaan draaien, is dit mogelijk met deze configuratie ? evt, wil ik gewoon patch .28 applien ?sp? op 8.2
Thnx voor jullie tijd !
Even een vraagje voor de ZFS veteranen
Algemene informatie
Ik heb onderstaande configuratie:
| # | Product | Prijs | Subtotaal |
| 5 | Samsung EcoGreen F4EG HD204UI, 2TB | € 60,- | € 300,- |
| 2 | Kingston ValueRAM KVR1333D3N9/4G | € 31,49 | € 62,98 |
| 1 | AMD Phenom II X6 1055T Boxed | € 128,- | € 128,- |
| 1 | MSI 880GM-E41 | € 54,68 | € 54,68 |
| Bekijk collectie Importeer producten | Totaal | € 545,66 | |
Nu loopt dit al een tijdje op Debian met een mdadm configuratie (daarop LVM+XFS)
Ik loop echter tegen een enorm hoog fragmentatie probleem aan (de machine word door meerdere gebruikt, vooral torrents en rtorrent werkt niet lekker mee).
Ik was al van plan te switchen naar ZFS toen ik de hardware binnen had maar ivm uitbreiden van de array heb ik dit niet gedaan, nu wil ik aankomende week toch switchen naar FreeBSD 8.2 met ZFS.
Vraag(en)
- Ik had gelezen dat 4 disks een performance verlies geeft (tegenover 3, 5 of 9 disks) ik ben dus van plan een extra disk aan te schaffen zodat het een raidz word met 5 disks, goed idee ?
- Ik was ook van plan om 8 GB ram bij te prikken voor ZFS, is dit nodig / wenselijk ?
- Performance technisch, wat ik reeel om te verwachtten ? momenteel is mijn lees en schrijfsnelheid vrij laag imo (rond de 50MB) kan dit met ZFS hoger worden ? (ik zal zowizo de 4k sectoren etc goed zetten in de config, dit moet ik nog even uitzoeken / lezen nav eerdere links in deze thread
- Gezien het een gezamelijke bak is (sort of) wil ik ook graag dedup gaan draaien, is dit mogelijk met deze configuratie ? evt, wil ik gewoon patch .28 applien ?sp? op 8.2
Thnx voor jullie tijd !
/u/10064/leuk_he.png?f=community)
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
Whoops, sorry, heb nu 4 disks, wil daar een 5e disk bij kopen, mijn OS staat op een 80Gb disk (momenteel 2x 80 in raid 1), ik heb in het overzicht eigenlijk alleen de relevante (naar mijn weten) informatie gezet, zodat het nog enigsinds overzichtelijk bleef
Anyway, 20Gb aan geheugen ... darnit .. ik zou dan 16 totaal hebben, met ongeveer 6 voor niet ZFS werk, eg, 10 Gb voor zfs.
Ik moet misschien maar even kijken naar een kleine SSD voor erbij (caching) als dat echt een groot verschil maakt.
PS, voor wat ik kan lezen kan de SSD altijd achteraf toegevoegd worden, dus in principe kan ik met deze config gewoon van start en later (indien nodig) een extra cache disk toevoegen.
EDIT:
/Edit: ja later toevoegen of je kunt dedup altijd uitzetten als hij geheugen gaat swappen daardoor.
Thnx, maar bottomline, zou dit systeem ZFS redelijk moeten kunnen handelen ? ik ben bereid consessies te doen uiteraard, maar ik zit niet op te wachtten op mega trage write/read speeds
Anyway, 20Gb aan geheugen ... darnit ..
ik zou dan 16 totaal hebben, met ongeveer 6 voor niet ZFS werk, eg, 10 Gb voor zfs.Ik moet misschien maar even kijken naar een kleine SSD voor erbij (caching) als dat echt een groot verschil maakt.
PS, voor wat ik kan lezen kan de SSD altijd achteraf toegevoegd worden, dus in principe kan ik met deze config gewoon van start en later (indien nodig) een extra cache disk toevoegen.
EDIT:
/Edit: ja later toevoegen of je kunt dedup altijd uitzetten als hij geheugen gaat swappen daardoor.
Thnx, maar bottomline, zou dit systeem ZFS redelijk moeten kunnen handelen ? ik ben bereid consessies te doen uiteraard, maar ik zit niet op te wachtten op mega trage write/read speeds
[ Voor 17% gewijzigd door YaNightmare op 20-05-2011 16:38 . Reden: Antwoord ]
Met 10 schijven lezen trek je dus inderdaad je gigabit verbinding wel vol. Schrijven niet helaas, valt toch wat tegen lijkt mij? Ik hoop eigenlijk zelf met 5 schijven wel tegen de limiet van gigabit te zitten, maar dit ga ik van het weekend zien, mijn moederbord is binnen :-D
@YaNightmare & @leuk_he:
Wat ik heb begrepen, is dat 1GB RAM per 1TB aangeraden wordt voor productieomgevingen, voor thuisgebruik is dit niet kritiek. Het geheugen wordt namelijk gebruikt als cache: ARC of L2ARC voor een SSD. Dit is dus vooral nuttig bij veel iops (webserver/sql), als je veel sequentiële data leest/schrijft (video/muziek) dan is het minder belangrijk. Maar met de huidige geheugen prijzen kan het natuurlijk geen kwaad er gewoon wat bij te prikken. Zeker als je eventueel ook nog met virtualisatie gaat werken.
Bij het in-of uitschakelen van dedup en compression moet je wel onthouden dat de nieuwe staat alleen voor nieuwe data geldt. Bestaande data wordt dus niet gecomprimeerd of "geduped". Wil je dit wel, dan zal je je pool opnieuw moeten aanmaken (en de data dus tijdelijk ergens anders opslaan).
Dus, ik zou lekker je huidige setup behouden met eventueel een extra disk om aan een "magic number" van schijven te komen. Mocht je eventueel meer RAM of een SSD willen, dat kan altijd.
Overigens wil ik me niet voordoen als guru, ik heb alleen nog maar systemen in virtuele machines getest Maar ik heb al wel aardig wat leesvoer doorgespit, vandaar dat je mij ook vaak links ziet posten. Dit alles is dus mijn eigen interpretatie, neem mee wat je nuttig lijkt
Ik heb geen removable NTFS devices in gebruik, dus ik zou het niet weten.
@YaNightmare & @leuk_he:
Wat ik heb begrepen, is dat 1GB RAM per 1TB aangeraden wordt voor productieomgevingen, voor thuisgebruik is dit niet kritiek. Het geheugen wordt namelijk gebruikt als cache: ARC of L2ARC voor een SSD. Dit is dus vooral nuttig bij veel iops (webserver/sql), als je veel sequentiële data leest/schrijft (video/muziek) dan is het minder belangrijk. Maar met de huidige geheugen prijzen kan het natuurlijk geen kwaad er gewoon wat bij te prikken. Zeker als je eventueel ook nog met virtualisatie gaat werken.
Bij het in-of uitschakelen van dedup en compression moet je wel onthouden dat de nieuwe staat alleen voor nieuwe data geldt. Bestaande data wordt dus niet gecomprimeerd of "geduped". Wil je dit wel, dan zal je je pool opnieuw moeten aanmaken (en de data dus tijdelijk ergens anders opslaan).
Dus, ik zou lekker je huidige setup behouden met eventueel een extra disk om aan een "magic number" van schijven te komen. Mocht je eventueel meer RAM of een SSD willen, dat kan altijd.
Overigens wil ik me niet voordoen als guru, ik heb alleen nog maar systemen in virtuele machines getest
Maar ik heb al wel aardig wat leesvoer doorgespit, vandaar dat je mij ook vaak links ziet posten. Dit alles is dus mijn eigen interpretatie, neem mee wat je nuttig lijkt
:strip_exif()/u/62088/sp_jh2.gif?f=community)
Haal je hier niet de ZIL en de L2ARC door elkaaar ? De L2ARC is uitbreiding van de ARC (read) cache, meestal een read-optimized (ssd mlc), maar die zie je volgens mij alleen bij de grotere installaties. De ZIL is je write cache voor je sync io. En die wordt idd voor sequentiele data vanaf een bepaalde blokgroootte niet gebruikt.
Je ARC statistieken kun je gebruiken om te bepalen of je een L2ARC-cache wilt hebben, maar de L2ARC kost ook weer ARC geheugen, dus meestal kun je beter de ARC (lees RAM) uitbreiden. Let ook op de ratio meta-/data van je ARC cache, daar kun je soms ook nog wat optimaliseren.....
Alles is natuurlijk flink afhankelijk van je working set, maar dit is wat ik de afgelopen dagen heb meegekregen van de Nexenta European User Conference en de CNE training erbij, met daarbij een van de ZFS devvers
BTW, ik ben ook helemaal geen guru, ZFS is nog vrij nieuw voor me, maar ben afgelopen dagen flink in het diepe gegooid, en flink kennis opgebouwd over de werking van ZFS. En ik ga er zeker meer mee doen
Edit: BTW, er is een nieuwe fork van OpenSolaris gemaakt, illumos. Ik denk dat dit een mooi open project is, en lijkt me een goed alternatief om ZFS op te draaien.
Edit2: Oh, niet zo heel nieuw meer, dat illumos, en hier al bekend (OpenIndiana) zie ik nu...
[ Voor 7% gewijzigd door u_nix_we_all op 20-05-2011 19:33 ]
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
Verwijderd
net andersom
(maar die snelheid kan wel wat omhoog zodra je een vdev erbij zet)
[ Voor 9% gewijzigd door Verwijderd op 20-05-2011 19:38 ]
Ik haal ze geloof ik niet echt door elkaar, ik bedoelde L2ARC als uitbreiding van ARC (vandaar dat het secondary level ARC heet:
[...]
Haal je hier niet de ZIL en de L2ARC door elkaaar ? De L2ARC is uitbreiding van de ARC (read) cache, meestal een read-optimized (ssd mlc), maar die zie je volgens mij alleen bij de grotere installaties. De ZIL is je write cache voor je sync io. En die wordt idd voor sequentiele data vanaf een bepaalde blokgroootte niet gebruikt.
Je ARC statistieken kun je gebruiken om te bepalen of je een L2ARC-cache wilt hebben, maar de L2ARC kost ook weer ARC geheugen, dus meestal kun je beter de ARC (lees RAM) uitbreiden. Let ook op de ratio meta-/data van je ARC cache, daar kun je soms ook nog wat optimaliseren.....
Alles is natuurlijk flink afhankelijk van je working set, maar dit is wat ik de afgelopen dagen heb meegekregen van de Nexenta European User Conference en de CNE training erbij, met daarbij een van de ZFS devvers
BTW, ik ben ook helemaal geen guru, ZFS is nog vrij nieuw voor me, maar ben afgelopen dagen flink in het diepe gegooid, en flink kennis opgebouwd over de werking van ZFS. En ik ga er zeker meer mee doen
Edit: BTW, er is een nieuwe fork van OpenSolaris gemaakt, illumos. Ik denk dat dit een mooi open project is, en lijkt me een goed alternatief om ZFS op te draaien.
Edit2: Oh, niet zo heel nieuw meer, dat illumos, en hier al bekend (OpenIndiana) zie ik nu...
) Maar je hebt wel gelijk mijn verhaal is eigenlijk alleen van toepassing op lees operaties. ZIL is inderdaad voor sync writers. Praktisch nadeel hiervan is dat je je ZIL cache eigenlijk moet mirroren, want als je een failure van je SSD(/disk) hebt, ben je simpelweg de ongeschreven data kwijt (maw financieel nadeel: aanschaf van nog een SSD ).Maargoed, volgens mij heeft eigenlijk niemand die ZFS voor z'n thuisserver gebruikt baat bij L2ARC of ZIL. Precies wat jij zegt lijkt mij het beste, lekker veel RAM voor een zo groot mogelijke ARC.
Nexenta European User Conference klinkt wel interessant, veel geleerd dus? Zijn er online presentaties? Nexenta is natuurlijk losjes verbonden aan OpenIndiana, gezien ze beide (toekomstig?) op Illumos gebaseerd worden, dacht ik.
ik heb een Supermicro AOC-USAS-L8i kaart. maar is wel dezelfde chipset geloof ik. is je probleem al opgelost?:
[...]
gebruikte jij nou ook een geflashte intel raid controller SASUC8I ?
zoja.. zou jij voor mij is kunnen kijken (via ssh) .. ik krijg steeds iets vreemds, welke disk/kabel ik ook pak.
' Failed to inquiry this logical disk '
[afbeelding]
format -e </dev/null | egrep "[0-9]\."
Verwijderd
had ik ook
ik wil gewoon een ntfs usb disk erin kunnen prikken en werken.
dat hotplug gebeuren werkt.. maar blijkbaar niet voor ntfs
Niet helemaal: De data van de ZIL wordt alleen teruggelezen bij systeemuitval, anders blijft het gewoon ook in de ARC staan en wordt daarvandaan geschreven. Dus geen probleem bij uitval van de ZIL. De ZIL levert je dus de snelle sync op write data op, maar moet die dus wel meteen non-volatile opslaan, zodat je integriteit bij uitval blijft. Dataverlies is er pas als je hele systeem uitvalt en de ZIL niet meer te lezen is.:
[...]
Ik haal ze geloof ik niet echt door elkaar, ik bedoelde L2ARC als uitbreiding van ARC (vandaar dat het secondary level ARC heet
Edit: snapshots FTW
Er werd wel wat gevideoot bij de presentaties , via die link kun je misschien e.e.a. vinden als ze dat daar posten.
En ja, enorm veel geleerd over ZFS, zie boven
Vooral het Copy on Write principe erachter is mooi, en de mogelijkheden die dat bied qua snapshots, dedup etc. Was natuurlijk wel op Nexenta gericht, maar 90% van de tijd ging het over ZFS
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
:strip_exif()/u/253566/Thunderdome-logo.gif?f=community){kind=logo}
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Iemand die nog op zoek is naar 1.5TB schijven? Kan ik mooi mijn schijven vervangen voor 2TB schijven om zo een 'mooier' aantal schijven te hebben om ZFS te draaien 
Even niets...
Andere wget's werken inderdaad ook niet. Heb Openindiana opnieuw geinstalleerd en kwam erachter dat het netwerk niet automatisch geconfigureerd wordt
Ik heb nu even geen tijd om dit verder uit te zoeken. Zal er vanavond mee verder gaan.
FreeBSD 9 met ZFSguru heeft nog steeds mijn voorkeur, maar zal Openindiana zeker nog een kans geven.
Weet nog iemand antwoord op de vraag wanneer FreeBSD 9 gereleased wordt?
[ Voor 16% gewijzigd door Kriss1981 op 21-05-2011 13:32 ]
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
De DDT (Dedup-table) staat in de metastore van de arc. Die kost je dus sowieso RAM. L2ARC toevoegen helpt niet echt qua RAM-verbruik, integendeel, de ARC heeft ook de pointers naar de L2ARC, en dat kan erg oplopen afhankelijk van de grootte van je L2ARC. Als je geen RAM wilt/kunt toevoegen zou je de ratio metastore/datacache kunnen wijzigen zodat je meer/genoeg ruimte in de metastore hebt voor de ddt en l2arc-pointers, maar dat kost je dan dus datacache ruimte in de arc. En de arc is nog steeds vele malen sneller dan l2arc, dus de vraag is of dat allemaal helpt.
In short:
Dedup is pas nuttig als je een flinke ratio haalt.
Wat je wint in diskruimte, betaal je gedeeltelijk terug in geheugengebruik.
When in doubt, add more RAM
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
/u/231803/ramdisk2.png?f=community)
Kun je dat uitleggen?
Afgezien van de web-interface zelf, kun je ZFSguru gebruiken om een root-op-ZFS installatie uit te voeren, waarmee je dus direct van je ZFS pool boot. Dat is gebaseerd op normaal FreeBSD, met voor-geinstalleerde meuk maar er niks uitgehaald zoals bij FreeNAS het geval is. Dus al gebruik je die hele web-interface niet dan nog is het handig om zo een installatie uit te voeren zonder gebruik van UFS, zeker voor mensen die net beginnen en command line toch iets te spannend vinden in het begin, is het best een aanrader.
Ben wel met je eens dat projecten die zijn uitgestorven minder aantrekkelijk zijn, maar of dat het geval is is maar even afwachten. Op de site staat inderdaad niks gemeld hieromtrent.
@Kriss27: hoe minder dingen je draaiend hebt, des te zuiniger. Een controller + notebookschijf zit je aan 2W tot 4W extra; echt niet veel en prima te doen, maar als het niet nodig is? Je hebt wel een argument om het OS op eigen disk te zetten als je je primaire schijven wilt laten downspinnen. Maar dat wil niet iedereen; om 15 seconden te wachten voordat ik wat aanklik vind ik niet erg fijn. Bovendien brengt het extra 'wear' met zich mee; HDDs blijven het liefst continu draaien en met een stabiele temperatuur. Up en downspinnen betekent dat je continu temperatuurschommelingen hebt wat hardeschijven over het algemeen niet zo fijn vinden. Ook zit je met Samsung F4 op 4W per schijf wat met 6 schijven dus op 24W neerkomt. Dan kun je er voor kiezen om die spindown lekker te laten zitten en je data altijd paraat te houden, of de spindown op een uur te zetten zodat het alleen 's nachts gebeurt ofzo.
Maar als je wel spindown wilt gebruiken, dan moet je het OS wel ergens anders neerzetten inderdaad, anders blijft er I/O komen en spinnen je disks dus nooit down.
Ik baseer mij op een reply op zijn forum. Ik heb zelf het alleen maar bekeken omdat ik nog geen tijd kon steken in het testen en niet zomaar wou overgaan naar ZFSguru. (Op datzelfde forum zie je ook topics verschijnen dat er al, relatief, tijden geen reactie van Jason is.):
[...]
Kun je dat uitleggen?
Afgezien van de web-interface zelf, kun je ZFSguru gebruiken om een root-op-ZFS installatie uit te voeren, waarmee je dus direct van je ZFS pool boot. Dat is gebaseerd op normaal FreeBSD, met voor-geinstalleerde meuk maar er niks uitgehaald zoals bij FreeNAS het geval is. Dus al gebruik je die hele web-interface niet dan nog is het handig om zo een installatie uit te voeren zonder gebruik van UFS, zeker voor mensen die net beginnen en command line toch iets te spannend vinden in het begin, is het best een aanrader.
Ben wel met je eens dat projecten die zijn uitgestorven minder aantrekkelijk zijn, maar of dat het geval is is maar even afwachten. Op de site staat inderdaad niks gemeld hieromtrent.
Dat ZFSguru het installeren makkelijker maakt is leuk, maar als de rest beperkt is dan zou ik toch liever of leren hoe het moet (en ik neem aan dat het makkelijker is in FreeBSD 9) of voor een andere optie kiezen. Want hoe lang blijft dit werken?
Maar goed, hopelijk komt er weer een teken van leven van Jason (letterlijk en figuurlijk), want het zag er wel erg interessant uit, helaas is het nu echt geen optie voor mij.
Beste test is een ramdisk aanmaken gevuld met data van /dev/random.
Direct benchen van /dev/random is niet te doen, want dat is veel te langzaam
Direct benchen van /dev/random is niet te doen, want dat is veel te langzaam
Even niets...
Klopt, daarom gebruikte ik ook al een file welke aangemaakt was (Had nodig voor wat andere dingen) om te CPen. Met dd haal ik een stuk langzamer, maar dat lijkt me heel logische.:
Beste test is een ramdisk aanmaken gevuld met data van /dev/random.
Direct benchen van /dev/random is niet te doen, want dat is veel te langzaam
Ik heb zo'n vermoeden dat het komt hoe ZFS werkt, o.a. met compressie e.d.
/dev/urandom is snel en pseudorandom (al eerder in deze thread besproken):
Direct benchen van /dev/random is niet te doen, want dat is veel te langzaam
Need more data. We want your specs. Ik ben ook maar dom. anders: forum, ff reggen, ff topic maken
En als je een oplossing hebt gevonden laat het ook ujb ff in dit topic horen.
@CiPHER (en andere)
Bedankt voor jullie info op ZFS gebied en opzet.
Ik denk dat ik uiteindelijk het volgende ga doen, 5x 2TB in raidz, 1x SSD (~60Gb) voor het OS (30Gb) met een partitie voor cache (rest ~30Gb) en totaal 16Gb geheugen.
PS, die 30 Gb is omdat mijn databases ook erop moeten draaien, die backuppen vervolgens naar de raid (idem met /etc) dus het OS in raid1 houden is niet echt nodig, plus een reinstall is een eitje als je een backup van /etc hebt.
ik zal later wel testen met dedup in realtime en als cron en kijken wat beter bevalt, gezien 50% van het takenpakket van deze machine race uploads zijn staat er namelijk veel dubbele data op, gemiddeld staat 80% van de series er dubbel op bijvoorbeeld, momenteel word dit handmatig en met scripts opgezocht en vervolgens worden er hardlinks gemaakt, maw, dedup zou hier een uitkomst zijn, maar als de performance extreem omlaag gaat zie ik geen probleem in een handmatige dedup
EDIT:
PS een tweede reden waarom ik het OS op een andere disk wil hebben is omdat ik op meerdere plaatsen lees dat ZFS de voorkeur geeft aan raw disks.
PPS, ik neem aan dat het handig is om met gnop de size op 4k te zetten van de disks ?
Bedankt voor jullie info op ZFS gebied en opzet.
Ik denk dat ik uiteindelijk het volgende ga doen, 5x 2TB in raidz, 1x SSD (~60Gb) voor het OS (30Gb) met een partitie voor cache (rest ~30Gb) en totaal 16Gb geheugen.
PS, die 30 Gb is omdat mijn databases ook erop moeten draaien, die backuppen vervolgens naar de raid (idem met /etc) dus het OS in raid1 houden is niet echt nodig, plus een reinstall is een eitje als je een backup van /etc hebt.
ik zal later wel testen met dedup in realtime en als cron en kijken wat beter bevalt, gezien 50% van het takenpakket van deze machine race uploads zijn staat er namelijk veel dubbele data op, gemiddeld staat 80% van de series er dubbel op bijvoorbeeld, momenteel word dit handmatig en met scripts opgezocht en vervolgens worden er hardlinks gemaakt, maw, dedup zou hier een uitkomst zijn, maar als de performance extreem omlaag gaat zie ik geen probleem in een handmatige dedup
EDIT:
PS een tweede reden waarom ik het OS op een andere disk wil hebben is omdat ik op meerdere plaatsen lees dat ZFS de voorkeur geeft aan raw disks.
PPS, ik neem aan dat het handig is om met gnop de size op 4k te zetten van de disks ?
[ Voor 11% gewijzigd door YaNightmare op 22-05-2011 18:03 . Reden: extra info/vragen ]
5x 2TB in RAID-Z is een optimale configuratie (qua 4K sector disks). Maar 6 disks in RAID-Z2 is dat ook en is gelijk een heel stuk veiliger. Tenzij je al andere backups hebt of de data niet heel erg cruciaal is, zou ik zelf voor RAID-Z2 gaan met 6 disks; dat is bijna niet kapot te krijgen! Maar in principe zal 5 disks in RAID-Z ook prima voor je werken; alleen voor echt cruciale data lijkt me dat te weinig bescherming.
Wat betreft SSD: kies een Intel SSD met supercap! Dan kun je hem veiliger als SLOG gebruiken. De Intel 320 serie is best goed, alleen is de write snelheid wel beperkt vooral voor modellen onder de 120GB. Zelf denk ik dat de 120GB versie de 'sweet spot' is, en dan 100GB gebruiken en 20GB als extra spare space overlaten; ongepartitioneerd dus. Althans zo zou ik het doen.
Als je Solaris platform gaat gebruiken kun je de SSD niet voor meerdere doeleinden gebruiken; Solaris kan namelijk geen flushes uitvoeren op partities wat de data-integriteit in gevaar brengt. Vandaar dat je gelezen hebt dat 'ZFS' graag ruwe device nodes wilt; maar dit is enkel van toepassing op Solaris platform en nadrukkelijk niet op FreeBSD platform! Onder FreeBSD (en verwante distributies) kun je prima een enkele SSD voor meerdere taken gebruiken:
- OS om van te booten
- primaire storage (ZFS, zoals je databases)
- L2ARC (random read cache)
- SLOG (sync write buffer)
Over dedup: je kunt dedup activeren alleen op filesystems met sterk identieke data, en het uitgeschakeld laten op de overige data waar je weinig winst zult behalen. Als meer dan 50% van de data identiek is, is dedup wel aardig om te gebruiken. Met name als de grootte niet zoveel oploopt en je lekker veel RAM en een L2ARC hebt, is dedup prima te doen. Wel zul je merken dat je CPU het zwaarder krijgt. In sommige gevallen kan dedup voor hogere performance zorgen, maar veel gemakkelijker kan het de performance van je systeem flink verlagen; dus testen en doe wat wijs is!
Over GNOP: dat hoef je niet te doen als je een optimale configuratie gebruikt, zoals RAID-Z met 5 disks of RAID-Z2 met 6 disks. Het kost je ook meer verloren ruimte, dus als het niet nodig is kun je het beter zo laten.
Wat betreft SSD: kies een Intel SSD met supercap! Dan kun je hem veiliger als SLOG gebruiken. De Intel 320 serie is best goed, alleen is de write snelheid wel beperkt vooral voor modellen onder de 120GB. Zelf denk ik dat de 120GB versie de 'sweet spot' is, en dan 100GB gebruiken en 20GB als extra spare space overlaten; ongepartitioneerd dus. Althans zo zou ik het doen.
Als je Solaris platform gaat gebruiken kun je de SSD niet voor meerdere doeleinden gebruiken; Solaris kan namelijk geen flushes uitvoeren op partities wat de data-integriteit in gevaar brengt. Vandaar dat je gelezen hebt dat 'ZFS' graag ruwe device nodes wilt; maar dit is enkel van toepassing op Solaris platform en nadrukkelijk niet op FreeBSD platform! Onder FreeBSD (en verwante distributies) kun je prima een enkele SSD voor meerdere taken gebruiken:
- OS om van te booten
- primaire storage (ZFS, zoals je databases)
- L2ARC (random read cache)
- SLOG (sync write buffer)
Over dedup: je kunt dedup activeren alleen op filesystems met sterk identieke data, en het uitgeschakeld laten op de overige data waar je weinig winst zult behalen. Als meer dan 50% van de data identiek is, is dedup wel aardig om te gebruiken. Met name als de grootte niet zoveel oploopt en je lekker veel RAM en een L2ARC hebt, is dedup prima te doen. Wel zul je merken dat je CPU het zwaarder krijgt. In sommige gevallen kan dedup voor hogere performance zorgen, maar veel gemakkelijker kan het de performance van je systeem flink verlagen; dus testen en doe wat wijs is!
Over GNOP: dat hoef je niet te doen als je een optimale configuratie gebruikt, zoals RAID-Z met 5 disks of RAID-Z2 met 6 disks. Het kost je ook meer verloren ruimte, dus als het niet nodig is kun je het beter zo laten.
[ Voor 6% gewijzigd door Verwijderd op 22-05-2011 20:20 ]
CiPHER,
Thnx, het is helemaal duidelijk, ik wil zowizo FreeBSD gaan draaien
Ik blijf SSD's erg duur vinden, maarja, tis niet anders in dit geval, ik moet zowizo nog even inlezen hoe SLOG werkt en hoe ik dat allemaal moet instellen
raidz is voor mij voldoende, ik heb genoeg backup ruimte voor de belangrijke data (ongeveer 4 TB in een andere machine met raid0 welke 1x per week rsynced) tevens, mocht alle data kwijt raken is dat voor mij niet het einde van de wereld (komt nog bij dat mijn mobo 6x SATA heeft, dus 5x 2Tb + 1xSSD is max).
Ben bang dat je me overtuigd hebt met die SSD, ik ga maar voor een Intel 320 120Gb.
Zou je nog willen delen met mij waarom je voor 100Gb zou gaan ipv 120 helemaal volmaken ?
En als je toch bezig bent, wat voor partities zou jij gebruiken (qua grootte van de L2ARC en SLOG ?) ik wil iets van 30 (of misschien 40 Gb) voor OS en databases (en wat web spul, maar das niet echt interessant qua ruimte gebruik.
Ik denk inderdaad dat ik met dedup maar gewoon wat moet gaan testen, ik heb een hexacore van AMD, dus qua proc power zou hij een heel eind moeten komen (of in iedergeval, dat is mijn gevoel).
PS, nogmaals super bedankt ! het is erg fijn wat tips te krijgen van iemand die wat meer weet van ZFS dan ik, tevens is googlen nog niet echt super wat betreft ZFS, er zijn veel verschillende meningen over wat de beste manier is
Thnx, het is helemaal duidelijk, ik wil zowizo FreeBSD gaan draaien
Ik blijf SSD's erg duur vinden, maarja, tis niet anders in dit geval, ik moet zowizo nog even inlezen hoe SLOG werkt en hoe ik dat allemaal moet instellen
raidz is voor mij voldoende, ik heb genoeg backup ruimte voor de belangrijke data (ongeveer 4 TB in een andere machine met raid0 welke 1x per week rsynced) tevens, mocht alle data kwijt raken is dat voor mij niet het einde van de wereld (komt nog bij dat mijn mobo 6x SATA heeft, dus 5x 2Tb + 1xSSD is max).
Ben bang dat je me overtuigd hebt met die SSD, ik ga maar voor een Intel 320 120Gb.
Zou je nog willen delen met mij waarom je voor 100Gb zou gaan ipv 120 helemaal volmaken ?
En als je toch bezig bent, wat voor partities zou jij gebruiken (qua grootte van de L2ARC en SLOG ?) ik wil iets van 30 (of misschien 40 Gb) voor OS en databases (en wat web spul, maar das niet echt interessant qua ruimte gebruik.
Ik denk inderdaad dat ik met dedup maar gewoon wat moet gaan testen, ik heb een hexacore van AMD, dus qua proc power zou hij een heel eind moeten komen (of in iedergeval, dat is mijn gevoel).
PS, nogmaals super bedankt ! het is erg fijn wat tips te krijgen van iemand die wat meer weet van ZFS dan ik, tevens is googlen nog niet echt super wat betreft ZFS, er zijn veel verschillende meningen over wat de beste manier is
Over de grootte van de SLOG: het heeft geen nut die groter te maken dan je RAM, het is namelijk een subset (de writes) van wat er in je ARC terecht komt. Ik denk dat je met een SLOG die half zo groot is als je RAM ruim voldoende hebt, tenzij je workload hoofdzakelijk uit sync writes bestaat.:
CiPHER,
Thnx, het is helemaal duidelijk, ik wil zowizo FreeBSD gaan draaien
Ik blijf SSD's erg duur vinden, maarja, tis niet anders in dit geval, ik moet zowizo nog even inlezen hoe SLOG werkt en hoe ik dat allemaal moet instellen
raidz is voor mij voldoende, ik heb genoeg backup ruimte voor de belangrijke data (ongeveer 4 TB in een andere machine met raid0 welke 1x per week rsynced) tevens, mocht alle data kwijt raken is dat voor mij niet het einde van de wereld (komt nog bij dat mijn mobo 6x SATA heeft, dus 5x 2Tb + 1xSSD is max).
Ben bang dat je me overtuigd hebt met die SSD, ik ga maar voor een Intel 320 120Gb.
Zou je nog willen delen met mij waarom je voor 100Gb zou gaan ipv 120 helemaal volmaken ?
En als je toch bezig bent, wat voor partities zou jij gebruiken (qua grootte van de L2ARC en SLOG ?) ik wil iets van 30 (of misschien 40 Gb) voor OS en databases (en wat web spul, maar das niet echt interessant qua ruimte gebruik.
Ik denk inderdaad dat ik met dedup maar gewoon wat moet gaan testen, ik heb een hexacore van AMD, dus qua proc power zou hij een heel eind moeten komen (of in iedergeval, dat is mijn gevoel).
PS, nogmaals super bedankt ! het is erg fijn wat tips te krijgen van iemand die wat meer weet van ZFS dan ik, tevens is googlen nog niet echt super wat betreft ZFS, er zijn veel verschillende meningen over wat de beste manier is
You don't need a parachute to go skydiving. You need a parachute to go skydiving twice.
Van FreeBSD heb ik de meeste kaas gegeten, dus daar kan ik je het meest bij helpen. Houd ook in je achterhoofd dat veel dingen die je 'op het web' leest over ZFS in feite Solaris-specifieke informatie is of kan zijn, en niet persé voor FreeBSD of andere platforms hoeft te gelden. Solaris blijft voorlopig het de-facto OS voor ZFS platforms, maar zelf zie ik meerdere redenen waarom dat op middel-lange termijn wel eens kan gaan veranderen. Zo hebben IllumOS en FreeBSD developers de handen ineengeslagen om ZFS verder te ontwikkelen. Het blijft natuurlijk afwachten hoe alles gaat, maar FreeBSD en ZFS is een veilige keuze en zal blijven bestaan en verder ontwikkeld worden, ongeacht wat Oracle gaat doen.:
CiPHER,
Thnx, het is helemaal duidelijk, ik wil zowizo FreeBSD gaan draaien
SSDs zijn duur als je naar de prijs per gigabyte kijkt, als je kijkt naar de prestatieverbetering per euro zijn ze eigenlijk heel goedkoop. Ook als je kijkt naar NAND versus DRAM is NAND gewoon stukken goedkoper. In de profi-wereld wordt NAND dan vooral als cheap gezien; wel grappig gezien de consumenten-visie is dat SSDs overpriced zijn. Daarbij mag je wel opmerken dat zakelijke klanten veel meer baat hebben bij Random I/O versnelling dan de doorsnee thuisgebruiker met vooral grote bestanden en een single-user achtig I/O patroon.Ik blijf SSD's erg duur vinden, maarja, tis niet anders in dit geval, ik moet zowizo nog even inlezen hoe SLOG werkt en hoe ik dat allemaal moet instellen
ZFS kan SSDs echter voor meerdere functies inzetten, en met weinig ruimte kun je al enorm veel winst boeken. Het gaat dus vooral om de snelheid van de SSD en niet de grootte, alhoewel die twee in de praktijk wel met elkaar verbonden zijn. Zo zie je bij veel SSDs, met name Marvell en Intel, dat grotere capaciteit SSDs ook direct sneller zijn qua writes. Qua reads nauwelijks/niet.
SLOG instellen is vrij makkelijk: zpool add tank log /dev/label/SLOGDISK
Je kunt de SLOG ook direct bij het aanmaken van de pool toevoegen, of later achteraf. Belangrijk is echter het volgende:
- SLOG is een potentiëel gevaarlijke feature; het zorgt ervoor dat de disks zelf géén ZFS Intent Log meer hebben, maar in feite wordt uitbesteed aan een dedicated log device "SLOG" (separate log device).
- Het afwezig zijn van SLOG of een gecrashde SLOG disk kan je hele pool onherstelbaar en unrecoverable maken, als je een ZFS pool versie lager dan 19 gebruikt. Vanaf versie 19 kun je SLOG disks verwijderen van de pool en bij afwezigheid een geforceerde import uitvoeren. Bij dit laatste worden enkele 'transaction groups' teruggerolt, wat betekent dat je een stuk terug in 'het verleden' gaat; recent gemaakte wijzigingen/writes ben je dan dus kwijt.
- Corruptie op je SSD kan dezelfde gevolgen hebben als hierboven vermeld. Dit komt vaak voor als een SSD onverwacht zijn stroom verliest. Daarom dat een SSD met 'supercapacitor' zoals de Intel 310/520 series eigenlijk verplicht is; anders draai je geen echt veilige setup.
Intel heeft standaard maar 6.8% spare space; het verschil tussen GB en GiB. Een 120GB Intel SSD heeft 120GiB aan NAND en daarvan is 120GB zichtbaar. Zie ook: Wikipedia: Binary prefix
Sommige SSDs zoals Sandforce SSDs hebben veel meer spare space, en dat is eigenlijk wel veel beter om performance-degradatie en een langere levensduur (lagere write amplification) te bewerkstelligen. Dat doe je door simpelweg niet alle plekken van de SSD te beschrijven. En dat doe je weer door een gedeelte niet te partitioneren en nooit te gebruiken voor iets. Je kunt het later weer resetten met een 'secure erase' wat alle door de host geclaimde ruimte weer terug te geven aan de SSD. Een verse schone SSD heeft dus 100% van de zichtbare ruimte als spare space en zodra je er naar gaat schrijven gaat de spare space omlaag. Door naar sommige plekken nooit te schrijven behoud je die ruimte vrij voor gebruik door de SSD; die intern aan remapping doet; een techniek die SSDs enorm veel sneller heeft gemaakt maar ook vatbaar voor performance degradatie.
Simpel gezegd, voor optimaal gebruik reserveer je 10-25% van de ruimte als extra space space; bovenop de vaste onzichtbare spare space die elke moderne SSD heeft. Sommige Sandforce modellen hebben standaard 35% onzichtbare ruimte, Intel heeft met 6.8% dus érg weinig spare space en dat kun je oplossen door bovengenoemde procedure, die ook wel 'overprovisioning' wordt genoemd. Professionele SSDs zoals FusionIO kun je instellen tussen 50 en 90% ofzoiets, naar gelang de afweging performance op lange termijn en levensduur enerzijds en opslagcapaciteit anderzijds.
4GiB SLOG
20GiB L2ARC
75GiB primary storage (ZFS pool met OS + database meuk)
de rest spare space
Ik zou GPT partities gebruiken, dat werkt netjes en mooi:
/dev/gpt/SLOG
/dev/gpt/SYSTEM
/dev/gpt/L2ARC
Nee SLOG wordt alleen gebruikt voor sync writes en die zijn per definitie niet meer nodig als de huidige transaction group is afgerond en volledig naar disk is gecommit. SLOG en ARC hebben dus niet veel met elkaar te maken. ARC is een caching-mechanisme voor performance-verbetering, SLOG/ZIL is een data-integriteit mechanisme vergelijkbaar journaling bij conventionele filesystems (UFS, Ext3/4, NTFS).
Je SLOG moet groot genoeg zijn om twee transactie groups te kunnen huisvesten, in principe kan 1 of 2GB genoeg zijn. Je hebt meer ruimte nodig niet als je meer RAM hebt, maar als je harddisk/pool sneller kan schrijven. Een pool die met 10GB/s kan schrijven (theoretisch) heeft dus een grotere SLOG nodig. Maar met zulke hardware kan ik niet testen.
Ik zou 4GiB aanhouden daar heb je zeker genoeg aan. Meer SLOG zal geen performancewinst geven. Het is voor je SSD ook fijn om deze ruimte klein te houden, zodat je SSD niet teveel fragmenteerd omdat de SLOG keer op keer wordt overschreven en hoe kleiner de LBA ruimte is waarop dat gebeurt des te beter. In feite schrijft je SSD vaak naar een andere plek, bijvoorbeeld de ruimte die je ongepartitioneerd hebt gelaten (spare space).
Wow, thnx !!!
Ik heb inmiddels al een aantal blog posts gelezen over ZFS om een beetje in de mood te komen en het is altijd handig als je een beetje begrijpt wat er onderwater gebeurt
Ik heb een 320 120Gb besteld woensdag haal ik hem op en ga ik over op een herinstall naar FreeBSD.
Mocht ik ergens tegenaanlopen laat ik het weten, en achteraf zal ik wat benchmarks draaien voor wie interesse heeft.
Wat betreft FS op de SSD neem ik aan dat UFS gewoon prima is voor de main install ? ik gok dat de ARC en SLOG geen FS nodig hebben.
BTW, no nooit met gpt gewerkt bedenk ik me nu ach, mijn arme virtual machine heeft het er zwaar mee met al dit testen hehe
Nogmaals bedankt voor de uitleg ! ik ben niet meer zo into hardware en nieuwe software technieken als vroeger, zo een duwtje in de rugt helpt dan wel
Ik heb inmiddels al een aantal blog posts gelezen over ZFS om een beetje in de mood te komen
en het is altijd handig als je een beetje begrijpt wat er onderwater gebeurt Ik heb een 320 120Gb besteld
woensdag haal ik hem op en ga ik over op een herinstall naar FreeBSD.Mocht ik ergens tegenaanlopen laat ik het weten, en achteraf zal ik wat benchmarks draaien voor wie interesse heeft.
Wat betreft FS op de SSD neem ik aan dat UFS gewoon prima is voor de main install ? ik gok dat de ARC en SLOG geen FS nodig hebben.
BTW, no nooit met gpt gewerkt bedenk ik me nu
ach, mijn arme virtual machine heeft het er zwaar mee met al dit testen hehe Nogmaals bedankt voor de uitleg ! ik ben niet meer zo into hardware en nieuwe software technieken als vroeger, zo een duwtje in de rugt helpt dan wel
:strip_icc():strip_exif()/u/64434/garfield_AIM2.jpg?f=community)
Dat heb ik inderdaad ook gelezen, maar volgens mij moet het niet veel kwaad kunnen voor de OS installatie, ik ben een beetje huiverig om ext4 oid te gaan draaien op FreeBSD.
En "on a sidenote" ik ben een redelijke voorstander van 1 partitie met daar gewoon alles op (geen aparte root, var etc) dus dat was ik van plan te doen, ik hou me namelijk niet altijd aan de regeltjes met welke data ik waar plaats en heb geen zin in partition full errors als ik een 4 gb file naar /tmp schrijf
EDIT:
Whoops over CiPHER zijn aanbeveling heen gelezen, ZFS voor OS it is
ik heb er wel zin in om woensdag hier allemaal aan te beginnen zeg ! waarschijnlijk trek ik na 2 uur mijn haren uit mijn hoofd, maar ik ben erg enthousiast over werken met ZFS en ik denk ook dat meer gebruikers = beter is, hopelijk gaat er daardoor lekker veel development tijd naartoe, ik hoop namelijk nog dit jaar die point rewrite functie in de roadmap te zien
[ Voor 23% gewijzigd door YaNightmare op 23-05-2011 17:42 ]
:strip_exif()/u/252890/walking.gif?f=community)
Vanzelf doen? smartd zou ik niet draaien, geeft ook problemen op LSI 1068E controllers. En aan die self-tests heb je geen bal aan. Mijn mening natuurlijk.
SMART is handig om zelf de data te interpreteren, ik heb nog nooit goede conclusies gezien van programma's die de interpretatie voor je uit handen nemen. smartd (de background daemon) draai ik dus ook bewust niet, ook vanwege de problemen met LSI controllers.
SMART is handig om zelf de data te interpreteren, ik heb nog nooit goede conclusies gezien van programma's die de interpretatie voor je uit handen nemen. smartd (de background daemon) draai ik dus ook bewust niet, ook vanwege de problemen met LSI controllers.
Als je UFS filesystem zeg 4 gigabyte groot is, dan heeft ZFS 4 gigabyte minder RAM ter beschikking. Best wel zonde om 4 gig 'weg te gooien' wat nutteloos in gebruik is. Alleen als de UFS filesystem ge-unmount wordt, heb je dit probleem niet. Bij het unmounten wordt al het geheugengebruik vrijgemaakt.
Als je ZFS filesystem écht je root (/) filesystem is, is het vreemd dat je hier niet rechtstreeks van kunt booten. Ik ken PC-BSD niet zo, maar je kunt ook mfsBSD proberen die ook een installscript heeft, of desnoods ZFSguru waarbij het ook vrij makkelijk is. Dan krijg je een echt 100% ZFS only systeem wat gewoon veel beter is dan ouderwets UFS. Dat is nu juist een voordeel van FreeBSD boven Solaris als ZFS NAS.
Maar hoe dan ook, als je boot partitie maar 1MB of minder is hoef je er niet moeilijk om te doen. Het gaat om de grootte van de bestanden die tenminste eenmalig worden ingelezen. Die grootte zie je dan als "Inact" geheugengebruik in de output van het "top" commando.
Als je ZFS filesystem écht je root (/) filesystem is, is het vreemd dat je hier niet rechtstreeks van kunt booten. Ik ken PC-BSD niet zo, maar je kunt ook mfsBSD proberen die ook een installscript heeft, of desnoods ZFSguru waarbij het ook vrij makkelijk is. Dan krijg je een echt 100% ZFS only systeem wat gewoon veel beter is dan ouderwets UFS. Dat is nu juist een voordeel van FreeBSD boven Solaris als ZFS NAS.
Maar hoe dan ook, als je boot partitie maar 1MB of minder is hoef je er niet moeilijk om te doen. Het gaat om de grootte van de bestanden die tenminste eenmalig worden ingelezen. Die grootte zie je dan als "Inact" geheugengebruik in de output van het "top" commando.
Weer genoeg leuke en interessante dingen gelezen hierboven, vooral jij lijkt goed in de materie te zitten CiPHER, gebruik je ZFS ook professioneel of is het allemaal hobby?
Ik ben zelf nog niet echt op gang gekomen, wat gedonder gehad met het installeren van OpenIndiana op een USB stick en wat weinig tijd. Wel even een heads-up voor de mensen die OI (willen gaan) gebruiken: vandaag staat build 151 op het programma: http://wiki.openindiana.org/oi/oi_151. Eerder vandaag werd opeens de release date op de wiki aangepast naar vandaag, weet niet of ze het nog gaan redden in 20 minuten, alhoewel, het is pas half 3 in het westen van de US
Er zijn volgens mij nog geen echte release notes volgens mij, dus het is nog een beetje een verrassing
Ik ben zelf nog niet echt op gang gekomen, wat gedonder gehad met het installeren van OpenIndiana op een USB stick en wat weinig tijd. Wel even een heads-up voor de mensen die OI (willen gaan) gebruiken: vandaag staat build 151 op het programma: http://wiki.openindiana.org/oi/oi_151. Eerder vandaag werd opeens de release date op de wiki aangepast naar vandaag, weet niet of ze het nog gaan redden in 20 minuten, alhoewel, het is pas half 3 in het westen van de US
Er zijn volgens mij nog geen echte release notes volgens mij, dus het is nog een beetje een verrassing
Volgens mijn zijn er tweakers die het wel op die manier doen. Het voordeel hiervan is dat ik maar een kachel in huis heb i.p.v. van twee van die dingen. Volgens mij betekend twee machines namelijk meer hardware kosten i.p.v minder.
Mocht ik toch voor een losse NAS gaan wat is er dan nodig voor een ZFS RAIDZ2/3 met 6 disken qua hardware (mobo/cpu/geheugen) Denk hierbij ook aan hoe groener hoe beter
* Bedenkt dat hij nog ergens een E2180 heeft liggen met een Asus P5***
* Bedenkt dat hij ook nog een SAS3041E heeft liggen maar dan strart ESXi niet meer op
Mocht ik toch voor een losse NAS gaan wat is er dan nodig voor een ZFS RAIDZ2/3 met 6 disken qua hardware (mobo/cpu/geheugen) Denk hierbij ook aan hoe groener hoe beter
* Bedenkt dat hij nog ergens een E2180 heeft liggen met een Asus P5***
* Bedenkt dat hij ook nog een SAS3041E heeft liggen maar dan strart ESXi niet meer op
[ Voor 23% gewijzigd door raymonvdm op 25-05-2011 10:43 ]
Deze setup had ik zelf ook min of meer in gedachten.
Handig om te weten dat het bij jou wel goed werkt. zelf heb ik een supermicro usas kaart ipv intel. maar dat is dezelfde chipset volgens mij. lsi?
maar ik wil wel vt-d met pci passthrough gaan gebruiken icm OI + napp it
Ik denk dat Cipher vooral erop doelt dat je voor specifieke taken een veel minder krachtig systeem kan bouwen.
En omdat je voor een storage VM toch vt-d wilt hebben zit er al een redelijke drempel op het gebied van hardware die daarbij hoort.
Persoonlijk heb ik een SB setup voor ESXi voor de vt-d .
Maar de langzaamste processor die je kunt gebruiken is dan een i5-2400. Toch niet echt langzaam. Of goedkoop. Daarnaast zit je voor SB redelijk vast aan Q67 chipset en voorzover ik heb gezien ben je dan ook meteen limited aan 1 16x slot. Dus maar 1 controller.
Voor mij persoonlijk kan ik absoluut niet zonder Virtualisatie vanwege school. En hobbby Lekker spelen.
Maar het ligt aan je situatie en wensen wat je het beste / goedkoopste / liefste moet doen.
Hoewel ik niet weet hoe dit op de oudere platformen zit. Maar er is vast wel iemand die daar wat over kan zeggen
En omdat je voor een storage VM toch vt-d wilt hebben zit er al een redelijke drempel op het gebied van hardware die daarbij hoort.
Persoonlijk heb ik een SB setup voor ESXi voor de vt-d .
Maar de langzaamste processor die je kunt gebruiken is dan een i5-2400. Toch niet echt langzaam. Of goedkoop. Daarnaast zit je voor SB redelijk vast aan Q67 chipset en voorzover ik heb gezien ben je dan ook meteen limited aan 1 16x slot. Dus maar 1 controller.
Voor mij persoonlijk kan ik absoluut niet zonder Virtualisatie vanwege school. En hobbby
Lekker spelen.Maar het ligt aan je situatie en wensen wat je het beste / goedkoopste / liefste moet doen.
Hoewel ik niet weet hoe dit op de oudere platformen zit. Maar er is vast wel iemand die daar wat over kan zeggen
Ik gebruik geen virtualisatie, op deze machines.
Wanneer ik virtuele machines nodig heb gebruik ik mijn beest van een desktop
.Ja deze gebruikt ook een LSI chipset. Ik ben tevreden van de setup:
[...]
Deze setup had ik zelf ook min of meer in gedachten.
Handig om te weten dat het bij jou wel goed werkt. zelf heb ik een supermicro usas kaart ipv intel. maar dat is dezelfde chipset volgens mij. lsi?
maar ik wil wel vt-d met pci passthrough gaan gebruiken icm OI + napp it
.
Dit is ook het gene wat in mijn wishlist staat zodat ik met een machine af kan.:
Ik denk dat Cipher vooral erop doelt dat je voor specifieke taken een veel minder krachtig systeem kan bouwen.
En omdat je voor een storage VM toch vt-d wilt hebben zit er al een redelijke drempel op het gebied van hardware die daarbij hoort.
Persoonlijk heb ik een SB setup voor ESXi voor de vt-d .
Maar de langzaamste processor die je kunt gebruiken is dan een i5-2400. Toch niet echt langzaam. Of goedkoop. Daarnaast zit je voor SB redelijk vast aan Q67 chipset en voorzover ik heb gezien ben je dan ook meteen limited aan 1 16x slot. Dus maar 1 controller.
Voor mij persoonlijk kan ik absoluut niet zonder Virtualisatie vanwege school. En hobbby
Maar het ligt aan je situatie en wensen wat je het beste / goedkoopste / liefste moet doen.
Hoewel ik niet weet hoe dit op de oudere platformen zit. Maar er is vast wel iemand die daar wat over kan zeggen
wenslijst: NAS Server
Ik wil alleen in delen opbouwen dus dacht nu alvast aan de disken en de controller en dan laster de rest. Ik heb al 2 x 2TB en wilde 4 x 2TB maar 6x2TB is een betere "best buy" optie dus daar gaan we nu maar voor.
Misschien is een andere moederbord nog een goeie optie maar dan wel met een Q67 chipset i.v.m met vt-d
[ Voor 3% gewijzigd door raymonvdm op 25-05-2011 11:32 ]