:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
Rebootje? 
Even niets...
:strip_icc():strip_exif()/u/25115/hshUE4j.jpg?f=community)
Uiteraard al geprobeerd
WTF. Het werkt. Ik moest een import doen op basis van disk-by-id en voila. Volume is nu groter geworden
WTF. Het werkt. Ik moest een import doen op basis van disk-by-id en voila. Volume is nu groter geworden
[ Voor 67% gewijzigd door nwagenaar op 05-02-2015 12:17 ]
:strip_icc():strip_exif()/u/3454/i486.jpg?f=community)
Zoals FD in zijn ZoL storage blog aanhaalt is het aanmaken en export/import op basis van /dev/disk-by-id "good practice" al is het maar omdat je dan je pool eigenlijk straffeloos kunt importeren als je een disk om steekt. Dit laatste geeft problemen als je /dev/sda aanhoudt.:
Uiteraard al geprobeerd
WTF. Het werkt. Ik moest een import doen op basis van disk-by-id en voila. Volume is nu groter geworden
Asrock Z77 Extreme6, Intel i7-3770K, Corsair H100i, 32 GB DDR-3, 256 GB Samsung SSD + 2 x 3TB SATA, GeForce GTX 660 Ti, Onboard NIC and sound, SyncMaster 24"&22" Wide, Samsung DVD fikkertje, Corsair 500R
Het is even belangrijk om enigzins een beeld te hebben van de load. 10 VMś die stil staan, genereren praktisch 0 load. 9 VMś die niks staan te doen, en 1 VM die continu staat te benchen, is natuurlijk weer een ander verhaal.
Mijn idee: Als je je VM's echt alleen zelf gebruikt, dus zonder enige echte (test-)gebruiker, kan je er wel 100 op een testclustertje draaien.
iSCSI, NFS of FibreChannel? (Of zelfs InfiniBand?, maar dat gok ik niet
)Compressie is niet zo duur (je hebt alleen een fatsoenlijke CPU nodig.
Deduplicatie is een verhaal apart, dat is echt een _hele_ zware optie. Het kost je veel RAM, en op een dataset van 20TB zou ik het niet eens aan durven zetten met 64GB geheugen.
Als je daarentegen Deduplicatie aan zet voor een 500GB-1TB LUN met VM's, hoef je je een stuk minder druk te maken.
Precies wat ik heb gedaan. Een lokale SSD voor de kleine Test VM's. Voor het grotere werk een paar HDD's.
Even niets...
Je kan ook eens proberen om in je BIOS ASPM uit te zetten... Ik heb ook wel eens een crashende Realtek NIC gehad omdat hij (door wat custom scripting enzo ) teveel in standby ging, en instabiel werd.
) teveel in standby ging, en instabiel werd.
Even niets...
Au Contraire Mon Capitan!
/u/1176/crop635f8931b2b68_cropped.png?f=community)
Het is misschien flauw, maar wel het beste advies wat er is voor mensen die zelf iets bouwen. Alleen Intel of HP nics voor mijn apparatuur. Anders alleen maar gezeik. En qua kosten hebben we het over tientjes werk.:
[...]
Een Intel nic kopen
/u/200133/artemis_square_e_60-60.png?f=community)
:strip_icc():strip_exif()/u/157053/crop574c68cea92df_cropped.jpeg?f=community)
Ik kan bevestigen dat WDTLER inderdaad helemaal niet werkt met de WD RED's. (not supported)
Misschien is GREEN toch een mooier kleurtje voor ZFS
Misschien is GREEN toch een mooier kleurtje voor ZFS
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
:strip_exif()/u/340453/crop67a669ce4f1f4_cropped.webp?f=community)
Wat je zegt klopt helemaal. Ik geloof dat je ongeveer rekening moet houden voor elke 5-10GB wat je aan L2ARC neemt, ongeveer 1GB aan geheugen moet reserveren. Doe je dat niet, dan kan inderdaad je performance flink zakken.
Elke situatie is natuurlijk anders, maar normaal gesproken is geheugen toevoegen het best wat je kan doen qua performanceverbetering.
:strip_icc():strip_exif()/u/27112/bierflesje_avatar.jpg?f=community){kind=avatar}
Ik heb nogal rare problemen met mijn ZFS-NAS.
Ik maakte eerst alleen gebruik van mijn Intel-controller waarop 1 SSD (OS+VMs) en 5x 3TB WD Greens zaten in RAID-Z1. Dit heeft een paar jaar probleemloos gewerkt.
Ik heb een half jaar geleden mijn setup bijgewerkt naar een wellicht nogal ongebruikelijk situatie: 1xSSD voor OS en 7x 3TB WD Greens in RAID-Z1. Om ruimteverlies tegen te gaan maak ik gebruik van ashift=9, de pool is dus optimized voor 512B sectoren. Deze keuze heb ik gemaakt omdat mijn mobo 8 SATA-poorten heeft en ik opslag belangrijker vindt dan performance.
De twee extra schijven heb ik aan de on-board ASMedia controller gehangen. Deze staan natuurlijk niet erg goed bekend, maar wederom: performance is redelijk ondergeschikt aan de opslag zelf. Daarnaast hoefde ik nu geen insteekkaarten te bestellen.
Dit draait over het algemeen prima, maar af en toe vliegen er ineens één of meerdere schijven uit. Deze komen dan naar boven met de status 'REMOVED'. Na een volledige power-down worden de schijven weer gevonden en is er niets meer aan de hand. Het gaat elke keer om dezelfde schijven op poort 3 en 4 van de Intel-controller. De load op het systeem is niet de aanleiding voor het offline gooien van de schijven. Dit gebeurt gewoon op willekeurige momenten. Deze momenten kunnen ook ver uit elkaar liggen. In de maand januari heeft het probleem zich helemaal niet voorgedaan en draaide alles prima.
Bij het analyseren van het probleem heb ik als eerste test de SATA-kabels vervangen op de probleempoorten. Helaas heeft dit niet geholpen, want het probleem deed zich weer voor. Als tweede test heb ik de schijven die op deze poorten stonden omgewisseld met de schijven die op poort 5 en 6 van de intel-controller zaten. Helaas wederom geen resultaat. Vanochtend was de pool weer unavailable en waren er 5(!) schijven met de status 'REMOVED'. De grap is dat alle schijven zijn uitgevallen, behalve juist de schijven op poort 3 en 4 van de Intel-controller
In het log is dit als volgt zichtbaar geworden:
Hebben jullie ideeën waar dit aan zou kunnen liggen? Ik heb zelf de volgende verdachten:
- ASMedia controller
- Moederbord
- Voeding
Ik draai ZFSGuru 0.2.0-beta10 op FreeBSD 10.0-STABLE (system image 10.1-001).
Ik maakte eerst alleen gebruik van mijn Intel-controller waarop 1 SSD (OS+VMs) en 5x 3TB WD Greens zaten in RAID-Z1. Dit heeft een paar jaar probleemloos gewerkt.
Ik heb een half jaar geleden mijn setup bijgewerkt naar een wellicht nogal ongebruikelijk situatie: 1xSSD voor OS en 7x 3TB WD Greens in RAID-Z1. Om ruimteverlies tegen te gaan maak ik gebruik van ashift=9, de pool is dus optimized voor 512B sectoren. Deze keuze heb ik gemaakt omdat mijn mobo 8 SATA-poorten heeft en ik opslag belangrijker vindt dan performance.
De twee extra schijven heb ik aan de on-board ASMedia controller gehangen. Deze staan natuurlijk niet erg goed bekend, maar wederom: performance is redelijk ondergeschikt aan de opslag zelf. Daarnaast hoefde ik nu geen insteekkaarten te bestellen.
Dit draait over het algemeen prima, maar af en toe vliegen er ineens één of meerdere schijven uit. Deze komen dan naar boven met de status 'REMOVED'. Na een volledige power-down worden de schijven weer gevonden en is er niets meer aan de hand. Het gaat elke keer om dezelfde schijven op poort 3 en 4 van de Intel-controller. De load op het systeem is niet de aanleiding voor het offline gooien van de schijven. Dit gebeurt gewoon op willekeurige momenten. Deze momenten kunnen ook ver uit elkaar liggen. In de maand januari heeft het probleem zich helemaal niet voorgedaan en draaide alles prima.
Bij het analyseren van het probleem heb ik als eerste test de SATA-kabels vervangen op de probleempoorten. Helaas heeft dit niet geholpen, want het probleem deed zich weer voor. Als tweede test heb ik de schijven die op deze poorten stonden omgewisseld met de schijven die op poort 5 en 6 van de intel-controller zaten. Helaas wederom geen resultaat. Vanochtend was de pool weer unavailable en waren er 5(!) schijven met de status 'REMOVED'. De grap is dat alle schijven zijn uitgevallen, behalve juist de schijven op poort 3 en 4 van de Intel-controller
In het log is dit als volgt zichtbaar geworden:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| Feb 8 21:16:28 zfsguru kernel: ada7 at ahcich7 bus 0 scbus7 target 0 lun 0 Feb 8 21:16:28 zfsguru kernel: ada7: <WDC WD30EZRX-00DC0B0 80.00A80> s/n WD-WMC1T0272598 detached Feb 8 21:16:28 zfsguru kernel: (ada7:ahcich7:0:0:0): Periph destroyed Feb 8 21:16:28 zfsguru kernel: ada6 at ahcich6 bus 0 scbus6 target 0 lun 0 Feb 8 21:16:28 zfsguru kernel: ada6: <WDC WD30EZRX-00DC0B0 80.00A80> s/n WD-WMC1T0194729 detached Feb 8 21:16:28 zfsguru kernel: (ada6:ahcich6:0:0:0): Periph destroyed Feb 8 21:16:38 zfsguru kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Feb 8 21:16:38 zfsguru kernel: ada0: <WDC WD30EZRX-00D8PB0 80.00A80> s/n WD-WMC4N1538790 detached Feb 8 21:16:38 zfsguru kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 Feb 8 21:16:38 zfsguru kernel: ada3: <WDC WD30EZRX-00DC0B0 80.00A80> s/n WD-WMC1T0176466 detached Feb 8 21:16:38 zfsguru kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Feb 8 21:16:38 zfsguru kernel: ada1: <WDC WD30EZRX-00D8PB0 80.00A80> s/n WD-WMC4N0865516 detached Feb 8 21:16:38 zfsguru kernel: (ada3:ahcich3:0:0:0): Periph destroyed Feb 8 21:16:38 zfsguru kernel: (ada1:ahcich1:0:0:0): Periph destroyed Feb 8 21:16:38 zfsguru kernel: (ada0:ahcich0:0:0:0): Periph destroyed |
Hebben jullie ideeën waar dit aan zou kunnen liggen? Ik heb zelf de volgende verdachten:
- ASMedia controller
- Moederbord
- Voeding
Ik draai ZFSGuru 0.2.0-beta10 op FreeBSD 10.0-STABLE (system image 10.1-001).
SRK35ZS-W
Mmm, rondje "m'n glazen bol" doet t vandaag ff niet.:
Ik heb nogal rare problemen met mijn ZFS-NAS.
Ik maakte eerst alleen gebruik van mijn Intel-controller waarop 1 SSD (OS+VMs) en 5x 3TB WD Greens zaten in RAID-Z1. Dit heeft een paar jaar probleemloos gewerkt.
Ik heb een half jaar geleden mijn setup bijgewerkt naar een wellicht nogal ongebruikelijk situatie: 1xSSD voor OS en 7x 3TB WD Greens in RAID-Z1. Om ruimteverlies tegen te gaan maak ik gebruik van ashift=9, de pool is dus optimized voor 512B sectoren. Deze keuze heb ik gemaakt omdat mijn mobo 8 SATA-poorten heeft en ik opslag belangrijker vindt dan performance.
De twee extra schijven heb ik aan de on-board ASMedia controller gehangen. Deze staan natuurlijk niet erg goed bekend, maar wederom: performance is redelijk ondergeschikt aan de opslag zelf. Daarnaast hoefde ik nu geen insteekkaarten te bestellen.
Dit draait over het algemeen prima, maar af en toe vliegen er ineens één of meerdere schijven uit. Deze komen dan naar boven met de status 'REMOVED'. Na een volledige power-down worden de schijven weer gevonden en is er niets meer aan de hand. Het gaat elke keer om dezelfde schijven op poort 3 en 4 van de Intel-controller. De load op het systeem is niet de aanleiding voor het offline gooien van de schijven. Dit gebeurt gewoon op willekeurige momenten. Deze momenten kunnen ook ver uit elkaar liggen. In de maand januari heeft het probleem zich helemaal niet voorgedaan en draaide alles prima.
Bij het analyseren van het probleem heb ik als eerste test de SATA-kabels vervangen op de probleempoorten. Helaas heeft dit niet geholpen, want het probleem deed zich weer voor. Als tweede test heb ik de schijven die op deze poorten stonden omgewisseld met de schijven die op poort 5 en 6 van de intel-controller zaten. Helaas wederom geen resultaat. Vanochtend was de pool weer unavailable en waren er 5(!) schijven met de status 'REMOVED'. De grap is dat alle schijven zijn uitgevallen, behalve juist de schijven op poort 3 en 4 van de Intel-controller
In het log is dit als volgt zichtbaar geworden:
code:
Welke Asmedia controller (wilde gok ASM1062)
Ik heb, voor een bekende, een kleine 2 jaar geleden een storage bakje op basis van een Asrock B75 Pro3-M (ASM0162 SATA) [Intel i3/16 GB RAM) in elkaar gezet. De SSD (OS) is aangesloten op de eerste SATA3 poort vd Intel chipset en de 6 SATA disks resp. 5x op de intel controller en 1 op de 1e poort vd Asm controller.
De bak draait ZFSguru, ik weet niet exact welke versie, maar in ieder geval niet de laatste.
Welke moederbord en zijn er meer meldingen mbt dit moederbord en SATA problemen?
Wederom welke voeding, wattage, leeftijd (grofweg), etc
Zou ik, op t eerste gezicht, geen problemen mee verwachten
Asrock Z77 Extreme6, Intel i7-3770K, Corsair H100i, 32 GB DDR-3, 256 GB Samsung SSD + 2 x 3TB SATA, GeForce GTX 660 Ti, Onboard NIC and sound, SyncMaster 24"&22" Wide, Samsung DVD fikkertje, Corsair 500R
De kabel-errors zijn al van voor dit probleem. Dat was een verrotte kabel die inmiddels is vervangen.
Ik zal als ik thuis ben nog wel even controleren hoe de schijven van stroom worden voorzien, kans is aanwezig dat dit ook via molex-splitters is gebeurd. Uiteindelijk worden de schijven wel middels de SATA-power kabels voorzien van stroom.
De inhoudelijk smart ziet er overigens ook overal netjes uit, geen leesfouten en dergelijke.
[ Voor 15% gewijzigd door Scooper op 09-02-2015 13:14 ]
SRK35ZS-W
Asrock Z77 Extreme6, Intel i7-3770K, Corsair H100i, 32 GB DDR-3, 256 GB Samsung SSD + 2 x 3TB SATA, GeForce GTX 660 Ti, Onboard NIC and sound, SyncMaster 24"&22" Wide, Samsung DVD fikkertje, Corsair 500R
/u/43643/security_tux.png?f=community)
Oh sorry, k had t er natuurlijk wel even bij kunnen zetten 
Voorbeeld van zo'n proces
code:
1
2
3
4
5
6
| last pid: 23395; load averages: 2.17, 2.06, 1.61 up 6+16:58:48 10:24:31 40 processes: 1 running, 38 sleeping, 1 zombie CPU: 0.4% user, 0.0% nice, 14.9% system, 0.6% interrupt, 84.1% idle Mem: 82M Active, 180M Inact, 2099M Wired, 80M Buf, 5514M Free ARC: 1024M Total, 88M MFU, 712M MRU, 18K Anon, 98M Header, 134M Other Swap: 4096M Total, 4096M Free |
Voorbeeld van zo'n proces
code:
1
2
| PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 14655 root 1 20 0 19356K 2836K zfs 4 0:00 0.00% rsync |
Voor wie er tegenaan loopt. Gisteren is mijn systeem schijf gecrashed. Gelukkig had ik netjes een backup op een externe schijf staan (met de rest van mijn belangrijke data). Dus even booten van een ZFSGuru live cd, vervolgens de backup instellen als systeem schijf:
Daarna even de fstab aanpassen naar de nieuwe locatie:
Daarna geboot van mijn backup schijf.
Om de backup weer zo snel mogelijk als backup terug te zetten heb ik vervolgens een USB stick ingericht als tijdelijke systeemschijf. Standaard partities (met boot) maken in ZFSGuru, daarna een nieuwe pool aangemaakt.
Vervolgens de systeem backup overgezet naar de USB stick;
Dan weer je /opt/etc/fstab aanpassen
Nu kan ik mooi vanaf mijn USB stick booten. Zodra de nieuwe schijf binnen is, maak ik een pool even groot als de huidige USB stick (16GB). Dan kan ik van de nieuwe schijf een mirror maken van de USB stick. Vervolgens haal ik de USB stick weer uit de mirror en heb ik mijn oude systeem weer terug
code:
1
| # zpool set bootfs=backup/server/zfsguru/10.1-001 backup |
Daarna even de fstab aanpassen naar de nieuwe locatie:
code:
1
2
3
4
| # zfs set mountpoint=/opt backup/server/zfsguru/10.1-001 # nano /opt/etc/fstab ... # zfs set mountpoint=legacy backup/server/zfsguru/10.1-001 |
Daarna geboot van mijn backup schijf.
Om de backup weer zo snel mogelijk als backup terug te zetten heb ik vervolgens een USB stick ingericht als tijdelijke systeemschijf. Standaard partities (met boot) maken in ZFSGuru, daarna een nieuwe pool aangemaakt.
Vervolgens de systeem backup overgezet naar de USB stick;
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| # zfs create xroot/zfsguru # zfs create xroot/zfsguru/10.1-001 # zfs create xroot/zfsguru/10.1-001/usr # zfs create xroot/zfsguru/10.1-001/var # zfs create xroot/zfsguru/10.1-001/var/log # zfs send backup/server/zfsguru/10.1-001@GMT-2015.02.09-00.00.00 | zfs receive xroot/zfsguru/10.1-001@GMT-2014.11.13-00.00.00 # zfs send backup/server/zfsguru/10.1-001/usr@GMT-2015.02.09-00.00.00 | zfs receive xroot/zfsguru/10.1-001/usr@GMT-2014.11.13-00.00.00 # zfs send backup/server/zfsguru/10.1-001/var@GMT-2015.02.09-00.00.00 | zfs receive xroot/zfsguru/10.1-001/var@GMT-2014.11.13-00.00.00 # zfs send backup/server/zfsguru/10.1-001/var/log@GMT-2015.02.09-00.00.00 | zfs receive xroot/zfsguru/10.1-001/var/log@GMT-2014.11.13-00.00.00 # zfs rollback xroot/zfsguru/10.1-001@GMT-2014.11.13-00.00.00 # zfs rollback xroot/zfsguru/10.1-001/usr@GMT-2014.11.13-00.00.00 # zfs rollback xroot/zfsguru/10.1-001/var@GMT-2014.11.13-00.00.00 # zfs rollback xroot/zfsguru/10.1-001/var/log@GMT-2014.11.13-00.00.00 # zpool set bootfs=xroot/zfsguru/10.1-001 xroot # zfs set mounpoint=/opt xroot/zfsguru/10.1-001 |
Dan weer je /opt/etc/fstab aanpassen
code:
1
2
| # zfs set mounpoint=legacy xroot/zfsguru/10.1-001 # reboot |
Nu kan ik mooi vanaf mijn USB stick booten. Zodra de nieuwe schijf binnen is, maak ik een pool even groot als de huidige USB stick (16GB). Dan kan ik van de nieuwe schijf een mirror maken van de USB stick. Vervolgens haal ik de USB stick weer uit de mirror en heb ik mijn oude systeem weer terug
Sinds de 2 dagen regel reageer ik hier niet meer
Staat er ergens compressie aan ofzo? Of deduplicatie?:
Oh sorry, k had t er natuurlijk wel even bij kunnen zetten
code:
Voorbeeld van zo'n proces
code:
Even niets...
@CurlyMo
Mooie mini how-to. Handig als je idd. geen mirrored OS pool draait (saved my butt the last time
)
Probeer de neiging om te rebooten (in de hoop dat de traagheid dan weg is) te beheersen want de scrub gaat vrolijk weer verder na de reboot. Maar zo aan de getallen te zien is de scrub straks gedaan.
Aha, lees net dat de scrub handmatig is aangezet.
Voor de duidelijkheid, wat is de upgrade geweest en hoe zit t met de vrije ruimte op t sticky??
Mooie mini how-to. Handig als je idd. geen mirrored OS pool draait (saved my butt the last time
)Nee dan nadert de snelheid vaak aan die van dikke pap door een trechter.:
Tja, met een scrub in progress zal het niet snel gaan sowieso
Probeer de neiging om te rebooten (in de hoop dat de traagheid dan weg is) te beheersen want de scrub gaat vrolijk weer verder na de reboot. Maar zo aan de getallen te zien is de scrub straks gedaan.
Aha, lees net dat de scrub handmatig is aangezet.
Voor de duidelijkheid, wat is de upgrade geweest en hoe zit t met de vrije ruimte op t sticky??
[ Voor 12% gewijzigd door Pantagruel op 10-02-2015 10:55 ]
Asrock Z77 Extreme6, Intel i7-3770K, Corsair H100i, 32 GB DDR-3, 256 GB Samsung SSD + 2 x 3TB SATA, GeForce GTX 660 Ti, Onboard NIC and sound, SyncMaster 24"&22" Wide, Samsung DVD fikkertje, Corsair 500R
Ik begin ondertussen nas4free te verdenken, dat ik 9.2 draaide was er 0 probleem en enkele weken na updaten krijg ik dit nu allemaal. Mogelijk maar eens een downgrade naar 9.2 inplannen... 
/u/116403/crop64cfe7aeafeb6_cropped.png?f=community)
Het zijn wel machines die gebruikt gaan worden door gebruikers. In het begin een 10 tal gebruikers, een samba server, een subversion server, een dhcp/dns server, een paar test db servers met naar alle waarschijnlijkheid redelijke datasets.
Mijn plan was om iSCSI te gaan gebruiken. FibreChannel of InfiniBand klinkt goed, als ik het zo na lees op internet, maar ik heb geen ide hoe ik het op moet zetten.iSCSI, NFS of FibreChannel? (Of zelfs InfiniBand?, maar dat gok ik niet
Ik zit op dit moment even te twijvelen tussen een Xeon E3 of een E5, oorspronkelijk was ik voor een Intel Xeon E5-1620 V3 gegaan, maar daarbij was ik er vanuit gegaan, dat er redelijk wat geheugen nodig was. Vanuit die gedachte een E5, want een E3 heeft natuurlijk een maximum van 64GB.
In principe ben ik geen deduplicatie/compressie nodig. Kan je deduplicatie aanzetten op een subgedeelte van je pool?
Ja, maar heb jij dan alles in 1 machine zitten, of heb je een SSD in de ESXi machine en de HDDs in een losse machine?
Zou je voor de veiligheid in de ESXi server 3 SSD's of HDD's in RAID-Z1 zetten, of wil ik dan te veel veiligheid creeren?
:strip_icc():strip_exif()/u/147640/van_hitomi_small_1_noborder.jpg?f=community)
Neemt elke 5 tot 10GB aan l2arc nu 1GB geheugen echt in, of is dit een richtlijn voor het alloceren van l2arc?:
[...]
Wat je zegt klopt helemaal. Ik geloof dat je ongeveer rekening moet houden voor elke 5-10GB wat je aan L2ARC neemt, ongeveer 1GB aan geheugen moet reserveren. Doe je dat niet, dan kan inderdaad je performance flink zakken.
Elke situatie is natuurlijk anders, maar normaal gesproken is geheugen toevoegen het best wat je kan doen qua performanceverbetering.
Solar @ Dongen: http://solar.searchy.net/ - Penpal International: http://ppi.searchy.net/
/u/217664/crop57a47149436c0_cropped.png?f=community)
Gewoon een 'zpool export <poolnaam>' zal zo'n stale pool doen vergeten. Je kunt bij het importeren ook een parameter meegeven die zorgt dat ZFS de pool niet onthoudt.
* nevermind, verkeerd gelezen *
Maar in dat geval: verwijder (destroy) je pool voortaan voordat je er een nieuwe opzet, al helemaal met dezelfde naam. Je kunt de naam trouwens wel veranderen, met het import commando. Zie 'man zpool' bij het kopje over import.
* nevermind, verkeerd gelezen
*Maar in dat geval: verwijder (destroy) je pool voortaan voordat je er een nieuwe opzet, al helemaal met dezelfde naam. Je kunt de naam trouwens wel veranderen, met het import commando. Zie 'man zpool' bij het kopje over import.
[ Voor 189% gewijzigd door Verwijderd op 14-02-2015 01:10 ]
/u/102334/avatar_mini.png?f=community){kind=avatar}
Ik heb het uiteindelijk opgelost door een zpool labelclear op alle partities:
Gewoon een 'zpool export <poolnaam>' zal zo'n stale pool doen vergeten. Je kunt bij het importeren ook een parameter meegeven die zorgt dat ZFS de pool niet onthoudt.
* nevermind, verkeerd gelezen
Maar in dat geval: verwijder (destroy) je pool voortaan voordat je er een nieuwe opzet, al helemaal met dezelfde naam. Je kunt de naam trouwens wel veranderen, met het import commando. Zie 'man zpool' bij het kopje over import.
Ander probleem dat nu ook bij m'n nieuwe NAS opgesteekt. L2arc die 'degraded' raakt.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| [root@nas /tank]# zfs-stats -L
------------------------------------------------------------------------
ZFS Subsystem Report Sat Feb 14 08:47:28 2015
------------------------------------------------------------------------
L2 ARC Summary: (DEGRADED)
Passed Headroom: 1.59m
Tried Lock Failures: 69.08k
IO In Progress: 1.12k
Low Memory Aborts: 14
Free on Write: 11.20k
Writes While Full: 104.89k
R/W Clashes: 38
Bad Checksums: 8.70k
IO Errors: 3.48k
SPA Mismatch: 105.37m
L2 ARC Size: (Adaptive) 385.20 GiB
Header Size: 0.19% 757.99 MiB
L2 ARC Evicts:
Lock Retries: 234
Upon Reading: 0
L2 ARC Breakdown: 1.84m
Hit Ratio: 3.48% 63.97k
Miss Ratio: 96.52% 1.77m
Feeds: 118.49k
L2 ARC Buffer:
Bytes Scanned: 44.07 TiB
Buffer Iterations: 118.49k
List Iterations: 6.72m
NULL List Iterations: 2.29m
L2 ARC Writes:
Writes Sent: 100.00% 108.50k
------------------------------------------------------------------------ |
In zpool iostat klopt de ruimte ook niet meer:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| capacity operations bandwidth
pool alloc free read write read write
----------------------- ----- ----- ----- ----- ----- -----
tank 1.61T 7.45T 3.41K 20 422M 83.9K
raidz2 1.61T 7.45T 3.41K 20 422M 83.9K
gpt/WD-WMC5C0D6E885 - - 891 5 55.5M 26.4K
gpt/WD-WMC5C0D7VE5C - - 882 5 55.5M 28.8K
gpt/9WM42LXF - - 867 4 55.4M 28.0K
gpt/9WM42E9G - - 857 5 55.4M 28.0K
gpt/9WM42LY8 - - 849 4 55.5M 28.8K
gpt/9WM3RW3J - - 860 4 55.5M 30.4K
gpt/WD-WCAU48917130 - - 684 4 55.5M 28.0K
gpt/WD-WCAU48917395 - - 679 4 55.3M 28.8K
gpt/WD-WCAU48917410 - - 724 4 55.5M 28.8K
gpt/WD-WCAU48917197 - - 687 5 55.4M 28.0K
logs - - - - - -
mirror 128K 3.97G 0 0 0 0
gpt/zil1 - - 0 0 0 0
gpt/zil2 - - 0 0 0 0
cache - - - - - -
gpt/l2arc1 198G 16.0E 0 0 0 0
gpt/l2arc2 184G 16.0E 0 0 0 0 |
Mijn l2arc bestaat uit 2 partities op m'n ssd (m550's) met elke 64G ruimte. In m'n andere NAS had ik een Crucial M500. Een soort gelijk issue heb ik hier gevonen: https://bugs.freenas.org/issues/5347 . Daar wordt het afgedaan als een hardware issue, maar ik heb nu een iets andere ssd en daar heb ik het zelfde issue (Is het verschil misschien te klein?)
Ik draai FreeBSD 10.1. Heeft er iemand anders ervaringen met m500 of m550 ssd's in l2arc?
Solar @ Dongen: http://solar.searchy.net/ - Penpal International: http://ppi.searchy.net/
dit probleem is er nog steeds, hij mist ongeveer ergens een TB aan freespace.
\\ Baloo \\ Mijn iRacing profiel
\\ Baloo \\ Mijn iRacing profiel
Client is een Synology, die spreekt Linux. Het NFS gedeelte klopt echt wel, want als ik een file neerzet op die share, zie ik 'em meteen in de Syno. Ik zal een poging wagen om te laten zien wat ik bedoel.
code:
1
2
3
4
5
6
7
8
9
10
11
| Cloudserver> ls -lrt drwxr-xr-x 2 root 1000 2 Feb 15 14:39 etc drwxr-xr-x 2 root 1000 2 Feb 15 14:39 foto drwxr-xr-x 2 root 1000 2 Feb 15 14:40 handycam drwxr-xr-x 2 root 1000 2 Feb 15 14:40 isootjes drwxr-xr-x 2 root 1000 2 Feb 15 14:40 mail drwxr-xr-x 2 root 1000 2 Feb 15 14:40 share drwxr-xr-x 2 root 1000 2 Feb 15 14:40 test drwxr-xr-x 2 root 1000 2 Feb 15 14:41 users drwxr-xr-x 2 root 1000 2 Feb 15 14:41 warez drwxr-xr-x 2 root 1000 2 Feb 15 14:41 web |
Alle files die je hier ziet zijn feitelijk clones van snapshots van filesystemen. Je verwacht dus dat wanneer ik naar de directory "test" navigeer, ik alle files uit die clone te zien krijg. Even checken:
code:
1
2
3
4
5
6
7
8
| Cloudserver> echo $PWD /volume1/fullbackup/hdtier Cloudserver> cd users Cloudserver> ls -lrt Cloudserver> ls -lart drwxr-xr-x 2 root 1000 2 Feb 15 14:41 . drwxrwxrwx 12 1000 1000 13 Feb 15 17:36 .. |
Als ik precies hetzelfde doe, maar dan op een Windows machine, zie ik die files uit "users" wel. Mijn conclusie: als je via NFS een gecloond filesysteem benadert, kan je geen gebruik maken van zfs pleziertjes. Maar wél via samba
Nog even, maar dan op de server zélf:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| [root@zfsguru /hdtier/etc/scripts]# cd /hdtier/fullbackup [root@zfsguru /hdtier/fullbackup]# ls -lrt total 154 drwxrwxrwx 2 share share 2 Apr 18 2014 share/ drwxrwxrwx 8 root wheel 8 May 9 2014 users/ drwxrwxrwx 149 root wheel 151 Sep 29 13:50 foto/ drwxrwxrwx 96 root wheel 104 Sep 30 20:15 handycam/ drwxrwxrwx 28 share share 30 Dec 12 11:50 web/ drwxrwxrwx 42 share share 115 Dec 12 13:15 warez/ drwxrwxrwx 13 share share 18 Feb 13 14:11 isootjes/ drwxrwxrwx 5 share share 5 Feb 14 14:03 etc/ drwxrwxrwx 15 share share 74 Feb 14 22:47 mail/ drwxrwxrwx 4 share share 5 Feb 15 11:54 test/ [root@zfsguru /hdtier/fullbackup]# cd users [root@zfsguru /hdtier/fullbackup/users]# ls -lrt total 115 drwxrwxrwx 2 gitje share 2 Nov 18 2010 Rens/ drwxrwxrwx 2 gitje share 2 Dec 16 2011 Maartje/ drwxrwxrwx 3 gitje share 4 Oct 22 19:58 Jelle/ drwxrwxrwx 15 gitje share 72 Nov 17 19:19 Mieke/ drwxrwxrwx 14 gitje share 38 Nov 20 21:54 Gitje/ drwxrwxrwx 35 gitje share 112 Dec 3 12:22 Hans/ |
vaag, toch?
Misschien ten overvloede, de mount vanaf de syno is als volgt:
code:
1
2
| /bin/mount 192.168.0.20:/hdtier/fullbackup /volume1/fullbackup/hdtier /bin/mount 192.168.0.20:/ssdtier/fullbackup /volume1/fullbackup/ssdtier |
[ Voor 27% gewijzigd door hansdegit op 15-02-2015 17:55 ]
nevermind, vorige post verkeerd gelezen
[ Voor 99% gewijzigd door FREAKJAM op 16-02-2015 08:53 ]
is everything cool?
En ik had het zo mooi bedacht... Alles mounten vanaf de Syno en dan mijn zfs server naar de Cloud backuppen middels Cloud Sync van Synology... 
Ik zou het toch eens proberen. Niet geschoten altijd mis
Sinds de 2 dagen regel reageer ik hier niet meer
Ik heb het verlossende antwoord gevonden. Het is een beperking van ZFS:
http://compas.cs.stonybrook.edu/downloads/zfs-over-nfs/
https://github.com/zfsonlinux/zfs/issues/616
Mijn setup hier werkt ook niet via NFS (ook als reactie op jou ):
CurlyMo in "Het grote ZFS topic"
http://compas.cs.stonybrook.edu/downloads/zfs-over-nfs/
https://github.com/zfsonlinux/zfs/issues/616
Mijn setup hier werkt ook niet via NFS (ook als reactie op jou
):CurlyMo in "Het grote ZFS topic"
Sinds de 2 dagen regel reageer ik hier niet meer
/u/362236/logo.JPG?f=community){kind=logo}
