mfi0: I/O error tijdens boot [FreeBSD/Nas4Free]

[kenvannen]

Ik krijg een error waar mijn Google-Fu niet tegen bestand is. Tijdens het opstarten krijg ik een volgende error reeks, herhaald in het oneindig:
mfi0: I/O error, [...]
mfi0: sense error 114, [...]
mfisyspd6: hard error cmd=read [...]

Als google resultaten krijg ik eventueel een firmware upgrade van de SAS kaart, of een stukke HDD uit trekken/vervangen. Ik heb een stukke HDD vervangen maar dit heeft geen resultaat gehad, naast het feit dat de stukke HDD reeds maanden niet gevonden werd dus zou vreemd zijn als dit plots een boot blokkeerd.

De NAS draait al een 4tal jaar. Na enkele maanden de boot disk moeten vervangen, sindsdien eigenlijk weinig problemen. Na een ~180 dagen uptime stond hij een weekendje koud, en een 6tal uur na booten was de netwerk schijf plots onbeschikbaar. Na reboot was zelfs de http pagina van de NAS onbeschikbaar.



...

(niet super gedetailleerd: de lijst van componenten staat uiteraard op de NAS. Oeps)
OS: NAS4Free 10.3.0.3.4374
Mobo: Supermicro X10SRL-F-O
CPU: Intel Xeon
SAS: 3 x IBM ServeRAID M1015 - 8 SATA poorten per PCI-e 2.0 x8 kaart.
HDD: 19x 6TB WD Red in ZFS+3 raid (WD60EFRX)
RAM: 64GB van op de Mobo's gevalideerde lijst
Boot SSD: Intel 80GB (vroeger een Sandisk 64GB USB stick maar wow ging die echt niet lang mee)
PSU: Corsair 850i
...

Google. weinig resultaten. Schijf vervangen met cold spare, lijkt geen effect te hebben. Weet echt niet waar begonnen.
...

[ Voor 140% gewijzigd door kenvannen op 01-11-2020 16:15 . Reden: (1) Prematuur gepost met Enter knop (2) Exactere hardware lijst gevonden + Image foutmelding ]

[Brahiewahiewa]

kenvannen schreef op zaterdag 31 oktober 2020 @ 20:39:
... Na een ~180 dagen uptime stond hij een weekendje koud...

Hmmz, dat is een uitgelezen manier om je disks te vernachelen. Weet je zeker dat alle disks opspinnen?

[kenvannen]

Brahiewahiewa schreef op zondag 1 november 2020 @ 03:13:
Hmmz, dat is een uitgelezen manier om je disks te vernachelen. Weet je zeker dat alle disks opspinnen?

Ik doe mijn best om ze 'warm' te houden maar ik moest weg en de UPS houdt het maar 15 minuten uit...

Ik ben niet 100% zeker dat ze allemaal opspinnen, maar de LSI firmware ziet ze alle 19. De stukke die ik net vervangen heb spinde inderdaad niet op maar dat probleem heb ik -door verschillende redenen- al maanden laten aanslepen dus lijkt mij weinig kans dat dat het probleem is.

[Brahiewahiewa]

kenvannen schreef op zondag 1 november 2020 @ 06:21:
[...] de LSI firmware ziet ze alle 19...

Dat betekent enkel dat de firmware van de disk werkt; niet noodzakelijk dat-ie opspint

Wat gebeurt er als je alle disks afkoppelt?
Als hij dan wel min of meer probleemloos opstart, zou dat wijzen op een probleem met de disks
Als hij dan niet opstart zou het probleem in (één van) de LSI controllers kunnen zitten

Zijn die LSI controllers overigens van die OEM modellen die je naar IT-mode hebt geflasht?

[kenvannen]

Brahiewahiewa schreef op zondag 1 november 2020 @ 15:56:
Dat betekent enkel dat de firmware van de disk werkt; niet noodzakelijk dat-ie opspint

Wat gebeurt er als je alle disks afkoppelt?
Als hij dan wel min of meer probleemloos opstart, zou dat wijzen op een probleem met de disks
Als hij dan niet opstart zou het probleem in (één van) de LSI controllers kunnen zitten

Dank je voor die verduidelijking. Heb in mijn leven al enkele tientallen schijven zien sneuvelen -toch 10+ in raid- maar deze distinctie is mij nog nooit opgevallen.

Als ik alle 6 de SAS->4xSATA kabels verwijder, boot NAS4Free inderdaad normaal. Ik zal alle 19 drives maar eens een SMART test laten doorstaan. Als de SMART test niks vindt kan het enkele weken duren voordat ik verder nieuws kan geven. Ik weet niet meer of het 11 uur of 18 uur was maar als ze nieuw waren hebben ze allemaal een WDDiag Erase test (full write dus) doorstaan, een extended (full read) zal nauwelijks korter zijn. En dat voor (tot?) 19 schijven uiteraard.

Brahiewahiewa schreef op zondag 1 november 2020 @ 15:56:
Zijn die LSI controllers overigens van die OEM modellen die je naar IT-mode hebt geflasht?

Mijn excuses, ik heb het opgezocht en het waren IBM M1015 raid sas kaarten. Mijn verwarring komt vast omdat tijdens boot "LSI Megaraid" getoond wordt. Maar die kwam zo out-of-the-box. Het lijkt me ook geen OEM, want ze kwamen in consumer-uitziende dozen toe.

Verder heb ik ze nooit geflashed; Wel was ik me van voor aankoop bewust dat het mogelijk was ze te flashen van Raid controllers naar SATA passthrough (als ik het juist vertel). Het enige voordeel daarvan dat ik me bewust ben is dat je 30 seconden tijdens booten wint (geen HDD/Raid checks door de controller). Aangezien ik voor de gezondheid van de HDDs de NAS doorgaans laat lopen (+/-4 cycle down/up per jaar van de schijven) leek het me uiteindelijk de moeite niet. KISS, dus 'as-is' gelaten.

Daarnaast heb ik in de OP een foto van de foutmelding toegevoegd en enkele hardware details ingevuld (mobo, SAS en HDD modellen).

[MainframeX]

kenvannen schreef op zondag 1 november 2020 @ 17:55:

[...]

Mijn excuses, ik heb het opgezocht en het waren IBM M1015 raid sas kaarten. Mijn verwarring komt vast omdat tijdens boot "LSI Megaraid" getoond wordt. Maar die kwam zo out-of-the-box. Het lijkt me ook geen OEM, want ze kwamen in consumer-uitziende dozen toe.

Verder heb ik ze nooit geflashed; Wel was ik me van voor aankoop bewust dat het mogelijk was ze te flashen van Raid controllers naar SATA passthrough (als ik het juist vertel). Het enige voordeel daarvan dat ik me bewust ben is dat je 30 seconden tijdens booten wint (geen HDD/Raid checks door de controller). Aangezien ik voor de gezondheid van de HDDs de NAS doorgaans laat lopen (+/-4 cycle down/up per jaar van de schijven) leek het me uiteindelijk de moeite niet. KISS, dus 'as-is' gelaten.

Die IBM M1015 kaartjes zijn met name populair in de ZFS scene omdat je ze in HBA modus kan draaien. Daardoor biedt de controller ze "kaal" aan voor ZFS om te gebruiken i.p.v. omsloten door een raid modus van de controller. In dat laatste geval zou ZFS maar één disk zien en dat is eigenlijk niet wat je wilt. De IT mode waar brahiewa naar refereerde is ook zoiets; bepaalde generaties LSI/Dell Perc controllertjes kan je naar een zogenaamde IT mode flashen zodat ze HBA mode ondersteunen.

Hoe ziet het vervangen van zo'n schijf in jouw setup eruit? Vervang je zo'n schijf en wordt er dan gelijk gerebuild of moet je de schijf resilveren in ZFS?

Het probleem dat je hier omschrijft komt in ieder geval op mij over als problemen met één raidcontroller/hba kaarten.

[kenvannen]

MainframeX schreef op woensdag 4 november 2020 @ 08:30:
Die IBM M1015 kaartjes zijn met name populair in de ZFS scene omdat je ze in HBA modus kan draaien. Daardoor biedt de controller ze "kaal" aan voor ZFS om te gebruiken i.p.v. omsloten door een raid modus van de controller. In dat laatste geval zou ZFS maar één disk zien en dat is eigenlijk niet wat je wilt. De IT mode waar brahiewa naar refereerde is ook zoiets; bepaalde generaties LSI/Dell Perc controllertjes kan je naar een zogenaamde IT mode flashen zodat ze HBA mode ondersteunen.

Tsja daarin ben ik een nieuweling. Dit is de eerste maal dat ik PCI-e Sata expanders gebruik zonder de RAID erop te gebruiken en hiervoor slechts 1 maal met RAID. De twee daarvoor via Raid op het mobo, en daarmee heb je ze alle 4. Wat ik bedoel is dus dat ik de controllers niet heb geflashed, ik zie de Raid firmware/software ze oplijsten net na BIOS, voor het OS boot, maar ze zijn alle 19 wel gewoon apart te zien voor FreeBSD/NAS4Free/XigmaNAS. Dus TLDR, volgens mij is het niet HBA (want Raid functionaliteit lijkt wel actief) maar ze zitten niet in een hardware raid.

MainframeX schreef op woensdag 4 november 2020 @ 08:30:
Hoe ziet het vervangen van zo'n schijf in jouw setup eruit? Vervang je zo'n schijf en wordt er dan gelijk gerebuild of moet je de schijf resilveren in ZFS?

Daar kan ik je helaas niet mee helpen. Er is al een goed jaar een disk stuk, en ik had een cold spare, maar (1) er waren nog 2 parities dus ondanks gebrek aan backup voelde ik me veilig genoeg, (2) ze zaten achter slot - leek mij 'steviger'-> minder vibraties, 20/20 hindsight, was het niet - en ik was de sleutel kwijt, en (3) langdurige persoonlijke problemen/kenmerken/... waardoor ik te weinig 'wilskracht' heb om te doen wat ik wil doen (te maken met langdurig ongediagnostiseerde autisme... hopelijk).

MainframeX schreef op woensdag 4 november 2020 @ 08:30:
Het probleem dat je hier omschrijft komt in ieder geval op mij over als problemen met één raidcontroller/hba kaarten.

Ik ben nog even bezig met de HDDs te checken. Heb je'n idee hoe ik de gezondheid van de Raid kaart kan testen?

[MainframeX]

kenvannen schreef op woensdag 4 november 2020 @ 10:38:
[...]

Ik ben nog even bezig met de HDDs te checken. Heb je'n idee hoe ik de gezondheid van de Raid kaart kan testen?

Je zou eventueel één voor één de kaarten uit een slot kunnen halen en kijken of de nas dan wel boot. Als het systeem dan niet over de zeik gaat met met booten, dan weet je in ieder geval welke van de drie kaarten problemen geeft.

Vervolgens zou je de probleemkaart eens terug kunnen plaatsen zonder de schijven aan te sluiten om te kijken je dan hetzelfde probleem krijgt. Als alle kaarten dezelde firmware draaien, dan kan je wel met redelijke zekerheid zeggen dat het raidkaartje kapot is.

[kenvannen]

MainframeX schreef op donderdag 5 november 2020 @ 23:24:
Je zou eventueel één voor één de kaarten uit een slot kunnen halen en kijken of de nas dan wel boot. Als het systeem dan niet over de zeik gaat met met booten, dan weet je in ieder geval welke van de drie kaarten problemen geeft.

Vervolgens zou je de probleemkaart eens terug kunnen plaatsen zonder de schijven aan te sluiten om te kijken je dan hetzelfde probleem krijgt. Als alle kaarten dezelde firmware draaien, dan kan je wel met redelijke zekerheid zeggen dat het raidkaartje kapot is.

Bedoel je dit anders dan SAS kabels eruit en booten? Want zo wilde hij eerder gewoon booten, wat voor mij dus leek dat vermoedelijk de controller kaarten okee waren.

[MainframeX]

@kenvannen Ja, dat bedoelde ik. Het blijft lastig te bepalen. Theoretisch gezien kan het een slechte poort op de kaart, SAS kabel of één van de schijven zijn. Voor de duidelijkheid; je weet al wel welke schijf problemen geeft die op de bewuste kaart aangesloten is? Dat is de schijf die je ook vervangen hebt?

[kenvannen]

MainframeX schreef op vrijdag 6 november 2020 @ 20:46:
@kenvannen Ja, dat bedoelde ik. Het blijft lastig te bepalen. Theoretisch gezien kan het een slechte poort op de kaart, SAS kabel of één van de schijven zijn. Voor de duidelijkheid; je weet al wel welke schijf problemen geeft die op de bewuste kaart aangesloten is? Dat is de schijf die je ook vervangen hebt?

Vergeef me als ik enkele termen verkeerd gebruik. Er was reeds een jaar een HDD stuk en dus was de volume Degraded. Maar het heeft gedurende dat jaar (of zo) wel prima gewerkt. Dus tussen "het werkt langdurig met een stukke HDD" en "Man, wat is dat een onduidelijke foutmelding" was ik best onzeker over wat ik moest doen, laat staan dat het een stukke HDD kon zijn. Jammer genoeg heb ik geen monitoring - enkel als ik manueel zin had om via de local website te kijken - noch backups. Die langdurig stukke schijf heb ik kort na starten van deze topic getest en hij ging zelfs niet aan.

Daarna heb ik de eerste 9 schijven - inclusief de cold spare - getest met de WD DIag software (Western Digital Data Lifeguard Diagnostics), met de 5 minuten test onder het mom van 'eerst een quick test en zien wat er af valt'. Allemaal prima. De 'achterste' 10 schijven komen er iets moeilijker uit - maar niet veel, de Lian Li D8000 is een prima kast - en heb ik om eigenlijk onbekende reden geswitcht naar volledige read test (+/- 12.5 uur per 6TB). Daar ben ik nu nog mee bezig, en ik wil puur uit interesse een sneltest + confirmatie test doen, maar ik heb er al (nog) een stukke schijf uitgehaald met "too many bad sectors". Hier heb ik geen cold spare voor, zal ik in't kort eentje voor bestellen. Om onbekende redenen zit ik te piekeren of ik niet het 8, 10 of 12TB model zou bestellen terwijl het identieke 6TB model beschikbaar is. Vreemd.

Anyway je vroeg min of meer om een update, dus:
(1) Er is nog niet succesvol geboot met de cold spare actief
(2) Zonder schijven, zonder SAS kabels, met Raid Controller kaarten boot alles prima
(3) De HDD tests zijn nog lopend, maar er is alvast 1 extra HDD gevonden die stuk is
(*) De Volume zou dus qua gezondheid nog 1 parity hebben met 1 spare die wacht op rebuild en 1 missing die wacht op aankoop

Hoop dat alles op een rijtje het iets duidelijker maakt

[MainframeX]

kenvannen schreef op zaterdag 7 november 2020 @ 04:48:
[...]
Om onbekende redenen zit ik te piekeren of ik niet het 8, 10 of 12TB model zou bestellen terwijl het identieke 6TB model beschikbaar is. Vreemd.

Dat hangt af of je plannen hebt om de set later uit te breiden. ZFS kan een raidz pool uitbreiden als je één voor één de schijven vervangt door grotere exemplaren. Als je dat niet van plan bent, dan heeft meer geld uitgeven niet zoveel zin.

Hoop dat alles op een rijtje het iets duidelijker maakt

Nou, ik ben nog steeds benieuwd naar hoe die raidset opgezet is. Dat je een mfi device krijgt vind ik apart, je zou verwachten dat bij hba de schijven kaal doorgezet worden naar zfs en dat devices als ada0, ada1 etc. krijgt.

Ik heb even gezocht en het lijkt er op dat er standaard een tooltje in FreeBSD geleverd wordt waar je misschien wat mee kan:

https://www.freebsd.org/c...i?query=mfiutil&sektion=8
https://mwl.io/archives/2105

Met mfiutil kan je dus je lsi megaraid kaart uitlezen/manipuleren. Zo zou je dus eventueel achter kunnen komen of je schijven zonder raid aan zfs gegeven worden (wenselijk) of dat deze omsloten door een hardware raid modus (dat werkt wel, maar is minder mooi).

Maargoed, niet te hard van stapel; ik ben eigenlijk wel benieuwd wat je zoal kan ontdekken met mfiutil. Dat is in ieder een tool die je wat meer antwoorden kan geven op de onduidelijkheden die je nu met de raidkaarten ervaart.

[ Voor 0% gewijzigd door MainframeX op 10-11-2020 20:49 . Reden: smartphones zijn volstrekt ongeschikt om op te typen maar ik doe het toch. ]

[kenvannen]

MainframeX schreef op dinsdag 10 november 2020 @ 20:48:
Dat hangt af of je plannen hebt om de set later uit te breiden. ZFS kan een raidz pool uitbreiden als je één voor één de schijven vervangt door grotere exemplaren. Als je dat niet van plan bent, dan heeft meer geld uitgeven niet zoveel zin.

*zucht* Ik weet niet of het door moe zijn komt, maar toen ik de schijven bestelde zat het in m'n hoofd dat het mogelijks door trillingen kwam - mogelijk maar onwaarschijnlijk. Dus steevast naar 'pro' modellen gekeken. Daar was een 6TB model eur220, een 12TB model eur320, koopje dus! Tsja, slecht zal het ook niet zijn zeker?

MainframeX schreef op dinsdag 10 november 2020 @ 20:48:
Nou, ik ben nog steeds benieuwd naar hoe die raidset opgezet is. Dat je een mfi device krijgt vind ik apart, je zou verwachten dat bij hba de schijven kaal doorgezet worden naar zfs en dat devices als ada0, ada1 etc. krijgt.

Ik heb even gezocht en het lijkt er op dat er standaard een tooltje in FreeBSD geleverd wordt waar je misschien wat mee kan:

https://www.freebsd.org/c...i?query=mfiutil&sektion=8
https://mwl.io/archives/2105

Met mfiutil kan je dus je lsi megaraid kaart uitlezen/manipuleren. Zo zou je dus eventueel achter kunnen komen of je schijven zonder raid aan zfs gegeven worden (wenselijk) of dat deze omsloten door een hardware raid modus (dat werkt wel, maar is minder mooi).

Maargoed, niet te hard van stapel; ik ben eigenlijk wel benieuwd wat je zoal kan ontdekken met mfiutil. Dat is in ieder een tool die je wat meer antwoorden kan geven op de onduidelijkheden die je nu met de raidkaarten ervaart.

Nou heb ik zelf ook niet stil gezeten en eventjes rond gekeken naar wat het flashen van de raid kaart zou inhouden. Zo zou het flashen gaan over een IBM M1015 - geproduceerd door LSI, met LSI in de boot tekst van de controllers alsook het LSI logo op de fysieke kaart - naar een LSI 9211 8i of zo.

Het was mij onduidelijk of dit nu voor of na het flashen zou zijn, maar een van de setups zou losse schijven doorgeven als elk zijnde een aparte JBOD - 19 schijven is dus 19 aparte JBODs. Het werd wel duidelijk dat zonder flashen de S.M.A.R.T. info niet (of nauwelijks) doorgegeven werd, wat verklaart waarom ik op de dag van falen slechts 1 stukke drive vond, en waarom die zijn serienummer nergens in de Nas4Free web interface te vinden was.

Ik ben nu klaar met alle 19+1 schijven een full read scan te doen.
- 16 schijven zijn okee
- 1 schijf start gewoon niet op (vermoedelijk PCB of geen stroomtoevoer?)
- 1 schijf heeft teveel 'bad sectors' en is dus ook onbruikbaar
- 1 schijf geeft 'bad sectors'. Kan nog gebruikt worden mits een full wipe. In mijn beperkte ervaring is er grote kans dat dit binnenkort toch stuk gaat, dus eruit.
- 1 cold spare is okee
- 2 nieuwe schijven gekocht, bezig met testen met full write (eerste indicatie lijkt op 24+ uren per schijf)

Goed, 3 schijven stuk dus, maar ik snap niet waarom de NAS niet wil booten. Was dit omdat de SMART info niet beschikbaar was, en een schijf die dus beschikbaar leek maar niet schrijven wou (too many bad sectors)? Je zal maar een setup met 10 pools hebben en plots boot de machine niet omdat er met 1tje een probleem is. Het kan natuurlijk wel maar lijkt me gewoon onlogisch.

Verder heb ik ook de raid controllers geflashed naar een doorgeefkaart. Deze guide gevolgd, vergeet niet de comment van Filippo te volgen. Het systeem boot nog steeds met alles geflashed, zonder de 6 SAS kabels, dus zelfde staat als voorheen. Behalve iets sneller booten dan. Verder mogelijks mijn eerste keer in de EFI shell dus hey, weer wat bijgeleerd. Denk wel dat het nu niet zinnig meer is de mfiutil te laten lopen?

Sowieso boot ik de NAS niet meer tot beide nieuwe schijven - na elk een full write test - erin gaan. Nog steeds wat hoop dat de data nog beschikbaar blijft mits geen backups. 3 schijven her- ... heu... hersilveren(?) is even zwaar als voor 1tje dacht ik...

[kenvannen]

Nou, goed nieuws, alle hardware en aanpassingen werken. Het disk management scherm toont plots ook veel meer info, i.i.g. de serie nummers, maar ik denk dat verschillende andere info d'r vroeger ook niet stond - of vager. Maar alle device IDs zijn veranderd - want is nu passthrough - alsook de controller IDs - want geflashed - dus... Tja. Ik heb nog alle data - en nog steeds geen backups, oei - maar dit kan mij wel een weekje duren voordat ik dit uitvis. Sidenote, plots is de boot disk gevonden, waar niks van is veranderd...

I.i.g. weet @MainframeX nu hoe de setup was:

[kenvannen]

MainframeX schreef op woensdag 4 november 2020 @ 08:30:
Hoe ziet het vervangen van zo'n schijf in jouw setup eruit? Vervang je zo'n schijf en wordt er dan gelijk gerebuild of moet je de schijf resilveren in ZFS?

Disks|Management|HDD Management -> Import Disks - Ik had geen apply gedaan maar dat werd blijkbaar toch opgeslaan. Had dit vorige keer niet opgemerkt, maar de SMB share is gewoon 'automatisch' beschikbaar. Vervolgens via Disks|ZFS|Pools|Tools|Replace a device een voor een de drie stukke schijven vervangen met de nieuwe. Die beginnen na vervangen automatisch te resilveren, info is te vinden via Disks|ZFS|Pools|Information (of I/O statistics):


Al is die 32h+ resilver tijd wat vreemd, een full write van 6TB is 12.5 uur, er wordt 37% capaciteit gebruikt, dus 12.5 (uur/schijf) * 0.37 (% data/schijf) * 3 (schijven) zou max 14 uur moeten zijn... Hopelijk belast hij de schijven niet door ze alle 3 tegelijkertijd maar niet met dezelfde data te resilveren (de 1e zit aan sector 1 miljoen, de ander aan sector 500k en de laatste aan sector 0).

Ik zal nog eens finaal posten als het resilveren gelukt/mislukt is, hoop je hiermee enkele antwoorden mee schuldig te zijn

[kenvannen]

Alles gelukt, met 1 anomalie: de drie nieuwe drives staan niet op filesystem 'ZFS Storage pool', wel op 'Unknown or unformatted'. Maar het resilveren is gelukt, en de pool staat op ONLINE. <edit> Had nog een "clear config and import disks" nodig in disk management scherm. Eerste afbeelding hieronder heeft weinig nut nu... </edit>

Daarnaast eens nageken over de rebuild tijd. De I/O deed did aan +/-20MB/s (hier 17.5MB/s als ik het goed lees). Beetje vreemd, de Xeon E5-2620 is nou ook niet de traagste (voor Z2 en Z3 parity berekeningen) maar goed. Mogelijks is dit om capaciteit te hebben voor "the pool will continue to function", of zit er toch ergens een bottleneck die ik niet begrijp zoals vb. synchronous read/write bandwidth ergens.

[ Voor 5% gewijzigd door kenvannen op 22-11-2020 07:22 . Reden: Meer info. ]

[MainframeX]

@kenvannen Ziet er goed uit Petje af hoor! Die unknown/unformatted meldingen in Nas4Free zijn wel vreemd, vooral omdat ZFS het allemaal goed lijkt te vinden nu. Kan je nu wel weer bij je data?

Resilveren kan soms gewoon echt ontzettend lang duren, vooral als je meerdere disks moet resilveren.

Het lijkt er trouwens ook of je van hardware raid modus overgegaan naar passthrough/hba modus (met name te zien aan je device names). In de praktijk heb ik zoiets nog niet eerder gezien, laat staan dat ik had verwacht dat dit zou werken. Heel gaaf.

Mocht alles naar behoren werken in ZFS, dan zou je eens kunnen overwegen om de pool te importeren in een Truenas Core installatie. Als ik me goed herinner is Nas4free een fork van FreeNas 9.x. Dat is inmiddels al behoorlijk oud (en naar mijn bescheiden mening erg spartaans vergeleken met het nieuwe FreeNas/TrueNas).

[kenvannen]

MainframeX schreef op zondag 22 november 2020 @ 23:08:
@kenvannen Ziet er goed uit Petje af hoor! Die unknown/unformatted meldingen in Nas4Free zijn wel vreemd, vooral omdat ZFS het allemaal goed lijkt te vinden nu. Kan je nu wel weer bij je data?

Unknown/Unformatted was weg na (opnieuw) een reimport van de disks. Vreemd dat het niet auto-update maar goed, schoonheidsfoutje. De data is eigenlijk nooit onbeschikbaar geweest, behalve toen ik overschakelde van raid naar HBA firmware, toen moest er wel eerst een (+/- 10 seconden) import van de disks gedaan worden. Maar goed, een ZFS3 waar 3 disks weg gevallen zijn gebruik ik niet uit principe.

MainframeX schreef op zondag 22 november 2020 @ 23:08:Resilveren kan soms gewoon echt ontzettend lang duren, vooral als je meerdere disks moet resilveren.

Tsja, ik zal het nooit weten. 17.5MB/s lijkt mij te snel om te zeggen dat 2 - laat staan 3 - schijven tegelijk op andere plekken aan het resilveren zijn. Ik werk al een decennium exclusief op SSDs - behalve NAS - maar in het verleden als je in windows 2 dingen tegelijk naar eenzelfde HDD kopieerde stortte de performance in ver onder de 17.5MB/s. Althans als ik mij dat goed herinner.

MainframeX schreef op zondag 22 november 2020 @ 23:08:Het lijkt er trouwens ook of je van hardware raid modus overgegaan naar passthrough/hba modus (met name te zien aan je device names). In de praktijk heb ik zoiets nog niet eerder gezien, laat staan dat ik had verwacht dat dit zou werken. Heel gaaf.

Yep. De metadata staat op de schijf zelf dus maakt het voor de pool blijkbaar weinig uit hoe de HDD aangesloten is. "Just works" en best cool.

MainframeX schreef op zondag 22 november 2020 @ 23:08:Mocht alles naar behoren werken in ZFS, dan zou je eens kunnen overwegen om de pool te importeren in een Truenas Core installatie. Als ik me goed herinner is Nas4free een fork van FreeNas 9.x. Dat is inmiddels al behoorlijk oud (en naar mijn bescheiden mening erg spartaans vergeleken met het nieuwe FreeNas/TrueNas).

Ik heb het niet gevolgd sinds ik mijn keuze heb gemaakt en dat is inmiddels 5(?) jaar geleden. Maar FreeNas => Truenas was een gratis optie van een commercieel product, gefocused op flashy uitziende extra features. Nas4Free => XigmaNas is FOSS of in die aard - zoals je zegt geforked in 2011 van FreeNas, gefocused op stabiliteit. De hoofdredenen dat ik op Nas4Free 10.3.0.3.4374 zit en niet op XigmaNas 12.1.0.4.7743 zijn het gebrek aan backups en KISS + If it ain't broke, don't fix it.

De naamsverandering naar XigmaNas was (+/-) trouwens omdat Nas4Free niet te copyrighten en/of trademarken was, te generieke term.