Het grote ZFS topic

[FREAKJAM]

Bij ZFSGuru ben ik niet heel erg bekend met de Root on ZFS variant. Ik had gister getracht 10.1-002 in een VM te installeren maar de "kale" variant (dus zonder schijven, enkel met vhd op esxi-niveau) wilde al niet booten. Wellicht deed ik iets verkeerd, maar volgens mij liep ik ongeveer tegen het volgende aan zoals hier beschreven.

Magoed, ik moet eerst de koe bij de horens zien te vatten. Ik zit op dit moment met een duplicate pool op schijven en dat moet ik eerst fixxen

[ Voor 5% gewijzigd door FREAKJAM op 25-11-2014 23:04 ]

[Compizfox]

Ah, right. Jep, da's een bekende bug. ZFSGuru gaat moeilijk doen als je probeert vanaf een pool te booten met ZFS versie v5000. Makkelijkste workaround is simpelweg om je system-pool op v28 te laten.

Anyway, ik zou het ook wel handig vinden als er in ZFSGuru de mogelijkheid komt om het systeem 'gewoon' op UFS te installeren. Ik bedoel, het is cool en alles dat FreeBSD kan booten vanaf een ZFS-pool (vanaf RAID-Z, zelfs), maar of het nou echt nodig is...

[ Voor 17% gewijzigd door Compizfox op 25-11-2014 23:09 ]

[Verwijderd]

Grootste voordeel van ZFSguru lijkt mij dat je een pure FreeBSD distributie hebt waar je onafhankelijk van ZFSguru alles mee kunt doen. Je begint met iets dat werkt, met goede config files voor ZFS, met een root-on-ZFS installatie. Maakt het allemaal makkelijk om te beginnen bij iets wat werkt, en te customizen hoe jij verder wilt indien nodig.

Over FreeBSD... 10.1 is best goed en ZFS is gewoon heel goed geïmplementeerd op BSD, met name de disk framework is superieur t.o.v. Linux - zie ook maar het laatste probleem met Ubuntu en ZoL. Daarnaast kun je ook nette GPT labels hebben voor je disks, wat ik veel netter vindt dan ID nummers want dat zegt een normaal mens niets.

Maar FreeBSD gaat pas echt leuk worden als bhyve goed gaat werken. Nu al kun je bhyve gebruiken voor sommige 64-bit Linux guests zoals Ubuntu. Alleen heeft bhyve nog geen VNC server bijvoorbeeld; ik zou graag een desktop Ubuntu op bhyve willen draaien en via VNC naartoe connecten. En geluid wil ik ook. Dat soort dingen duurt nog wel even heb ik het idee. Voor server dingen is bhyve al bruikbaar. Sinds kort werkt bhyve ook met AMD virtualisatie; alleen weet ik niet of dat ook in 10.1 is opgenomen.

FreeBSD vs. Linux is zeker persoonlijke voorkeur. Dat gezegd, FreeBSD is omdat het kernel+userland+portstree is een echt compleet OS en derhalve ook makkelijk te leren omdat je niet continu verschillen hebt tussen distributies. FreeBSD heeft ook een uitstekende 'FreeBSD handbook' handleiding, ook in het Nederlands. Al met al is FreeBSD vooral leuk voor servers en Linux universeler en ook als desktop te gebruiken. Is Linux je ding dan zou ik daarbij blijven, tenzij je je horizon wilt verbreden.

[FREAKJAM]

Compizfox schreef op dinsdag 25 november 2014 @ 23:08:
Ah, right. Jep, da's een bekende bug. ZFSGuru gaat moeilijk doen als je probeert vanaf een pool te booten met ZFS versie v5000. Makkelijkste workaround is simpelweg om je system-pool op v28 te laten.

Anyway, ik zou het ook wel handig vinden als er in ZFSGuru de mogelijkheid komt om het systeem 'gewoon' op UFS te installeren. Ik bedoel, het is cool en alles dat FreeBSD kan booten vanaf een ZFS-pool (vanaf RAID-Z, zelfs), maar of het nou echt nodig is...

Agree, een embedded installer zou top zijn. Op v28 boot hij inderdaad wel. Thanks.

[Q]

Ha, meteen ff vraag over ZFS Root. Want er is maar 1 zfs pool onder BSD. Maar ik wil mijn OS op een RAIDZ1 (SSD) en de data op bijv een RAIDZ2 (disks) zetten, maar volgens mij werkt dat niet zo !?...

Fuck ik ben stom, gewoon andere pool maken !

[ Voor 10% gewijzigd door Q op 25-11-2014 23:26 ]

[Verwijderd]

FREAKJAM schreef op dinsdag 25 november 2014 @ 23:17:
Agree, een embedded installer zou top zijn. Op v28 boot hij inderdaad wel. Thanks.

Als je v5000 boot op Root-on-ZFS met ZFSguru wilt, kan ik je een paar instructies geven als je wilt. Het is een issue die in de volgende release (december) opgelost zal zijn. Het gaat om nieuwe bootcode die je nodig hebt voor je disks.

Een embedded distributie had ZFSguru in het verleden voor USB sticks. Werkt sinds 0.1.7 ofzo niet meer, dat was een complete rewrite. Nog voor mijn tijd.

Maar in plaats van een embedded dist ben ik ook al bezig met een Root-on-RAM (RoR) distributie. Dat betekent dat tijdens boot de systeemimage wordt uitgepakt op een tmpfs memory disk en dat je root (/) filesystem wordt. Vervolgens worden persistent changes in een aparte archive bewaard die je kunt backuppen en ervoor kunt kiezen om tijdens het afsluiten deze automatisch bij te werken.

Voordeel is net als Embedded dist. dat je snel kunt werken met trage USB sticks die ultratraag zijn met random writes. Daarnaast vind ik een heel groot voordeel dat je niet meer afhankelijk bent van fysieke disks voor je operating system. Stel je hebt een kabelprobleem, dan dondert niet gelijk je operating system onderuit omdat die gewoon in RAM staat. Hooguit stokt je Samba/NFS/iSCSi even. Maar dat kan ik beter hebben dan dat het hele OS gaat trippen omdat de OS disk opeens vastloopt.

Q schreef op dinsdag 25 november 2014 @ 23:18:
Ha, meteen ff vraag over ZFS Root. Want er is maar 1 zfs pool onder BSD. Maar ik wil mijn OS op een RAIDZ1 (SSD) en de data op bijv een RAIDZ2 (disks) zetten, maar volgens mij werkt dat niet zo !?...

Kan toch gewoon? Je kunt hooguit één actieve pool hebben om van te booten. Bij ZFSguru kun je op System->Booting page aangeven welke installatie de actieve installatie is waarvan wordt geboot als je reboot, maar je kunt dat prima ook met native FreeBSD doen. Simpelweg de 'bootfs' goed instellen.

[duiveltje666]

Wat ik graag zou zien :
De Services installable als zijnde ports , desnoods met default ( door het project bepaalde) settings/configfiles , zodat je gewoon je packages up2date kunt houden ..
Gebruik Zfsguru al vanaf de 8.x release en het is gewoon annoying dat ik per se de packages zou moeten blijven gebruiken ipv de ports.
Heb zelf nu mijn install volledig optimized voor de gebruikte hardware ( en oa Vuurvoske en Compizfox geadviseerd/geholpen destijds)..
Indien dit gerealiseerd kan worden (desnoods ook met profiles voor make.conf voor bijv diverse Intel en AMD Cpu's ) zou ZFSguru imho nog completer zijn

[nero355]

Ik weet niet hoe het bij ZFSguru allemaal in elkaar zit, maar je kan bij een normale FreeBSD installatie gewoon alle packages via de ports updaten.

Dus alles wat je via pkg_add -r installeert kan je updaten via cvsup + /usr/ports/ indien nodig

[duiveltje666]

nero355 schreef op woensdag 26 november 2014 @ 02:33:
Ik weet niet hoe het bij ZFSguru allemaal in elkaar zit, maar je kan bij een normale FreeBSD installatie gewoon alle packages via de ports updaten.

Dus alles wat je via pkg_add -r installeert kan je updaten via cvsup + /usr/ports/ indien nodig

dat klopt .. maar bijv de sabnzbd package is gebouwd voor php 5.4 specifiek(ivm spotweb) .. mainstream is 5.5 tegenwoordig
en pkg_add -r haalt het niet bij de ports zelf qua opties

[Verwijderd]

duiveltje666 schreef op woensdag 26 november 2014 @ 02:22:
Wat ik graag zou zien :
De Services installable als zijnde ports , desnoods met default ( door het project bepaalde) settings/configfiles , zodat je gewoon je packages up2date kunt houden ..

Dat kan toch ook? Services installeren pkgNG packages. Daarnaast worden soms custom config files geïnstalleerd en worden desktop shortcuts geïnstalleerd als het om een grafische service gaat.

Kortom, na het installeren van de service kun je deze prima met pkgNG updaten. Er zijn uitzonderingen, zoals de extra apps in de SABnzbd+ service die helemaal niet beschikbaar zijn in de FreeBSD portstree.

Gebruik Zfsguru al vanaf de 8.x release en het is gewoon annoying dat ik per se de packages zou moeten blijven gebruiken ipv de ports.

Wat bedoel je precies? Want ZFSguru gebruikt juist ports ipv distributie packages. Je kunt ook via portstree updaten met portmaster/portupgrade. Dus ik snap niet precies wat je bedoelt?

duiveltje666 schreef op woensdag 26 november 2014 @ 02:40:
dat klopt .. maar bijv de sabnzbd package is gebouwd voor php 5.4 specifiek(ivm spotweb) .. mainstream is 5.5 tegenwoordig

FreeBSD heeft 5.4 nog als default. Niet zonde reden: bepaalde software werkt simpelweg niet met 5.5, dus 5.4 is een betere/veiligere default versie. De performance voordelen van 5.5 worden veelal overdreven. Denk niet dat je ZFSguru sneller zal draaien als je zou updaten. Maar ZFSguru zelf zou prima moeten werken op 5.5. ZFSguru heeft ook in /etc/make.conf de 'default_versions' ingesteld die je gemakkelijk kunt aanpassen van 5.4 naar 5.5 als je wilt.

en pkg_add -r haalt het niet bij de ports zelf qua opties

pkg_add is oude stijl packages, pkg is pkgNG - de nieuwe generatie package mangement. Dat is wat ZFSguru gebruikt. Je kunt daarvan ook de port options zien en je kunt ook prima binaire updates doen van packages. Werkt allemaal veel beter dan het oude systeem.

[Compizfox]

duiveltje666 schreef op woensdag 26 november 2014 @ 02:22:
Wat ik graag zou zien :
De Services installable als zijnde ports , desnoods met default ( door het project bepaalde) settings/configfiles , zodat je gewoon je packages up2date kunt houden ..
Gebruik Zfsguru al vanaf de 8.x release en het is gewoon annoying dat ik per se de packages zou moeten blijven gebruiken ipv de ports.
Heb zelf nu mijn install volledig optimized voor de gebruikte hardware ( en oa Vuurvoske en Compizfox geadviseerd/geholpen destijds)..
Indien dit gerealiseerd kan worden (desnoods ook met profiles voor make.conf voor bijv diverse Intel en AMD Cpu's ) zou ZFSguru imho nog completer zijn

Ik ben het met je eens, maar je hoeft geen packages te gebruiken als je dat niet wilt. Zelf gebruik ik het ook nooit; ik gebruik gewoon de ports en dat gaat prima.

Wat CiPHER zegt is ook gewoon correct: ik heb in het verleden wel eens een service geinstalleerd via de webinterface, en hem dan geupdate via de ports. Gaat prima.

[ Voor 8% gewijzigd door Compizfox op 26-11-2014 11:30 ]

[justice strike]

heeft iemand eigenlijk al eens een van die avaton bordjes getest? Dat ziet er namelijk vrij interessant uit. 12 sata poorten + 2 nics. Alleen wel jammer dat ze 250 euro per stuk kosten. Das een beetje aan de prijzige kant.

[matty___]

Voor de liefhebbers:
http://www.open-zfs.org/wiki/OpenZFS_Developer_Summit_2014

Videos en slides van de OpenZFS dev Summit

[EnerQi]

justice strike schreef op woensdag 26 november 2014 @ 16:10:
heeft iemand eigenlijk al eens een van die avaton bordjes getest? Dat ziet er namelijk vrij interessant uit. 12 sata poorten + 2 nics. Alleen wel jammer dat ze 250 euro per stuk kosten. Das een beetje aan de prijzige kant.

pricewatch: ASRock C2550D4I <-- deze heb ik in gebruik (NAS 2).
Werkt goed met ZFSguru maar ik gebruik 'm als opslag, niet voor andere zaken.

[Verwijderd]

Ik meen me te herinneren dat de ASrock Avoton bordjes een stabiliteits firmware fix nodig hadden? Voor de Marvell controller; volgens mij komt dat samen met de BIOS update maar dat weet ik niet zeker.

[CurlyMo]

@Compizfox: wat @CiPHER zegt is niet helemaal correct, want ik heb sterk het idee dat @duiveltje666 hetzelfde probeert te zeggen als wat ik in het ZFSGuru discussie topic ook al een paar keer uiteengezet heb. Ik ga dat hier alleen niet herhalen

[justice strike]

EnerQi schreef op woensdag 26 november 2014 @ 17:14:
[...]


pricewatch: ASRock C2550D4I <-- deze heb ik in gebruik (NAS 2).
Werkt goed met ZFSguru maar ik gebruik 'm als opslag, niet voor andere zaken.

Ziet er goed uit dat bordje, maar is ansich wel erg duur voor een atom systeem.

[ikkeenjij36]

@Cipher je hebt een pb.
Groet

[FREAKJAM]

MikeVM schreef op dinsdag 25 november 2014 @ 14:30:
[...]

hoe weet je welke zfs versie je hebt?

apt-cache policy spl spl-dkms ubuntu-zfs zfs-dkms is wellicht ook een handig commando voor als je Ubuntu draait. Dan zie je naast het feit welke versie je draait, welke versie er eventueel te verkrijgen is.

[ Voor 3% gewijzigd door FREAKJAM op 26-11-2014 19:35 ]

[iMars]

Even een vraagje. Ik zie dat de laatste D525 vragen uit 2011 komen.

Nu heb ik zelf de Supermicro X7SPA-HF-D525 met nu nog 4GB ram geheugen, maar ik lees dat er ook 8GB in kan.

Hoe zou de performance zijn als ik 4x 2TB in RAIDZ zet, met een caching SSD en 8GB ram op een 1.8 Ghz Intel Atom? Het is 64bits, maar geen VT-x en VT-d support....

[ Voor 8% gewijzigd door iMars op 26-11-2014 20:35 ]

[IceTeaGX]

Voor een ZFS server zal dat geen probleem zijn, snelheid zal waarschijnlijk niet top zijn.
VT-x heb je enkel nodig voor virtualisatie.

[duiveltje666]

Compizfox schreef op woensdag 26 november 2014 @ 11:29:
[...]

Ik ben het met je eens, maar je hoeft geen packages te gebruiken als je dat niet wilt. Zelf gebruik ik het ook nooit; ik gebruik gewoon de ports en dat gaat prima.

Wat CiPHER zegt is ook gewoon correct: ik heb in het verleden wel eens een service geinstalleerd via de webinterface, en hem dan geupdate via de ports. Gaat prima.

Klopt Lars , maar icm sommige packages is dat gewoon kut , ik wil php5.5 wegens stuk more responsive , echter pakt die spotweb service dat niet..
Die packages zouden iets meer generic qua packages gemaakt moeten worden tevens zou jij als geen ander moeten weten hoeveel tijd ik in het tweaken van mn make.conf e.d. ten behoeve van mn ports heb gestoken..

[ Voor 3% gewijzigd door duiveltje666 op 27-11-2014 02:13 ]

[FireDrunk]

iMars schreef op woensdag 26 november 2014 @ 20:32:
Even een vraagje. Ik zie dat de laatste D525 vragen uit 2011 komen.

Nu heb ik zelf de Supermicro X7SPA-HF-D525 met nu nog 4GB ram geheugen, maar ik lees dat er ook 8GB in kan.

Hoe zou de performance zijn als ik 4x 2TB in RAIDZ zet, met een caching SSD en 8GB ram op een 1.8 Ghz Intel Atom? Het is 64bits, maar geen VT-x en VT-d support....

4GB kan ook prima hoor, zelfs 2GB zou ik nog wel aandurven. Je ARC wordt dan gewoon kleiner, en je zal bij het inlezen van hele grote videobestanden wat lagere performance zien... Het is niet zo dat het ding tergend langzaam wordt ofzo. Denk eerder aan een verschil van 200MB/s ipv 300MB/s ofzo.

[justice strike]

nog een vraagje. Volgens mij was iemand hier bezig om watt per gigabyte in kaart te brengen. De conclusie was dat laptop hd's het beste waren. Maar volgens mij is da nu anders met de wester digital green drives van 6 tb. Iemand die daar iets over kan vertellen?

tevens ben ik nog wel benieuwd of je met ssd (cache of slog) ook daadwerkelijk kunt voorkomen dat je hdd's weer opspinnen. Ik kan daar namelijk weinig over vinden.

[ Voor 24% gewijzigd door justice strike op 27-11-2014 11:42 ]

[FireDrunk]

Dat is lang geleden gedaan volgens mij, en intussen zijn die laptopschijven volgens mij alweer ingehaald door bijvoorbeeld de nieuwe NAS hdd's van Seagate (VN000) pricewatch: Seagate NAS HDD, 4TB

Deze deden volgens mij in use 4.8W en idle nog minder (~3W ofzo).

De grootste Laptop harddisk van het moment is volgens mij 2TB en doet iets van 1.5W.
In verhouding is de 4TB dus beter want als je watt/GiB combineert met €/GiB wint de 4TB dus.

Over je tweede vraag:

Mijn ervaring is dat het voor lezen werkt.
Voor metadata sowieso, voor ARC en L2ARC voor zover ik weet ook, maar je kan niet een complete file in L2ARC forceren (omdat het op blockniveau werkt), waardoor je nooit zeker weet dat je schijven niet opspinnen bij het benaderen van een specifieke file.

Voor schrijven werkt het nooit, SLOG is alleen een tijdelijke stable storage voor synced writes, niet een compleet write-buffer / cache. Bij elke write zal je pool opspinnen.

[FREAKJAM]

We zijn weer online (in ieder geval met een lege pool). Tijdens het veilig stellen van mijn data waren er een aantal meer bestanden corrupt geraakt (i/o error tijdens het kopieren).

Ik heb nu even vlug ZoL in Debian geinstalleerd. Even kijken waar ik het uiteindelijk allemaal ga parkeren.

code:

sudo zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Thu Nov 27 12:14:41 2014
config:

        NAME                                           STATE     READ WRITE CKSUM
        tank                                           ONLINE       0     0     0
          raidz2-0                                     ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0565854  ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0328511  ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0565375  ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0237419  ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0245360  ONLINE       0     0     0
            scsi-SATA_WDC_WD30EFRX-68_WD-WMC4N0565098  ONLINE       0     0     0

[FireDrunk]

Gebruik alsjeblieft niet die device id's

Als je van ZFSguru afkomt, kan je beter doen:

zpool import -d /dev/disk/by-partlabel/ [poolnaam]

Krijg je keurig netjes je GPT labeltjes.

[FREAKJAM]

In Linux kun je geen gpt labels maken is het wel? (kan er weinig over vinden in ieder geval)

Ik had de drives nu zo geformat:

code:

parted --align=opt /dev/sdb
(parted) mklabel gpt
(parted) mkpart primary 2048s 100%

Ik zie mijn drives ook niet op basis van by-partlabel.

code:

 ls -l
total 0
drwxr-xr-x 2 root root 720 Nov 27 13:01 by-id
drwxr-xr-x 2 root root 360 Nov 27 13:01 by-path
drwxr-xr-x 2 root root  80 Nov 27 12:47 by-uuid

[ Voor 7% gewijzigd door FREAKJAM op 27-11-2014 13:44 ]

[FireDrunk]

The ZFS Storage Blog!: ZFSonLinux - Hoe partitioneer ik nou mijn schijven?

[HyperBart]

Q schreef op dinsdag 25 november 2014 @ 09:20:
Met de hoeveelheid data die sommige mensen hebben is een backup financieel niet haalbaar. Dan moet je eigenlijk twee NASsen naast elkaar gaan draaien, of een bij kennissen/familie neerzetten. Duur grapje.

Wat redelijker is, is dat je een subset backupped, van de data die 'echt' belangrijk is en van de rest accepteert dat het verloren kan gaan. Gezien de data waar het meestal om gaat, is dat niet zo'n issue.

Dat mijn Video-share waar series en films in staan niet gebackupped is zal me worst wezen. Dat alle digitale foto's van mijn ouderlijk gezin en documenten niet gebackupped worden is een ander paar mouwen.

Pro-tip: hou ook een zogenaamd "cold" archive bij. Ik heb nu op een 400GB schijfje alle foto's staan.

Recentere foto's en de oude subset worden regelmatiger gebackupped, maar die liggen vaak offline in dezelfde kamer. Tja, als er daar brand uit breekt ben ik wel het haasje... Daarom heb ik een cold archive wat bij mijn ouderlijk huis ligt.

[FREAKJAM]

FireDrunk schreef op donderdag 27 november 2014 @ 13:46:
The ZFS Storage Blog!: ZFSonLinux - Hoe partitioneer ik nou mijn schijven?

Held Punt blijft wel dat er geen "by-partlabel" aanwezig is in mijn Debian VM, maar dat ligt wellicht aan Debian (heb zojuist 2 disks al geformat op basis van je guide).

[FireDrunk]

probeer eens:

udevadm trigger

[FREAKJAM]

Doet niets, maar valt me op dat mijn Ubuntu 14.04 waar ik voorheen ZFS op had draaien het ook niet heeft. Ik ga de pool en labels eens aanmaken in ZFSGuru en exporteren. Eens kijken wat er dan gebeurt.

[Pantagruel]

HyperBart schreef op donderdag 27 november 2014 @ 14:03:
[...]



Dat mijn Video-share waar series en films in staan niet gebackupped is zal me worst wezen. Dat alle digitale foto's van mijn ouderlijk gezin en documenten niet gebackupped worden is een ander paar mouwen.

Pro-tip: hou ook een zogenaamd "cold" archive bij. Ik heb nu op een 400GB schijfje alle foto's staan.

Recentere foto's en de oude subset worden regelmatiger gebackupped, maar die liggen vaak offline in dezelfde kamer. Tja, als er daar brand uit breekt ben ik wel het haasje... Daarom heb ik een cold archive wat bij mijn ouderlijk huis ligt.

Films en series zijn doorgaans wel weer te rippen/vinden en niet t einde van de wereld. Doc's, foto- en film materiaal van de familie is een eenmalige zaak en die mag idd best wat aandacht verdienen.

Als een off-site back-up geen optie is dan is enige vorm van 'cold storage' wel aan te bevelen. Zelf rouleer ik 2 stuks externe 2 TiB disks (bus powered dus behalve het kabeltje en de disk geen andere shit nodig) tussen thuis en m'n locker op t werk.

Binnen de familie is er gemompel over off-site back-ups van de groeiende digitale data en ik heb de knuppel in t hoenderhok gegooid door voor te stellen om onderling voor elkaar als off-site back-up te gaan dienen (onderlinge afstanden liggen tussen de 140 en 300 km) in de vorm van een ZFS servertje.
Ze stonden nou niet meteen te juichen (Mm, waarom nou zeg 6x 3Tib kost slechts ca. 540 ; de rest van de hardware komt uit de recycle doos), dus voorlopig zal 't bij ieder zijn eigen crashplan abo-tje blijven (€60 per jaar)

[FireDrunk]

FREAKJAM schreef op donderdag 27 november 2014 @ 15:12:
Doet niets, maar valt me op dat mijn Ubuntu 14.04 waar ik voorheen ZFS op had draaien het ook niet heeft. Ik ga de pool en labels eens aanmaken in ZFSGuru en exporteren. Eens kijken wat er dan gebeurt.

Die directory komt pas, als er daadwerkelijk GPT labels zijn

[Compizfox]

duiveltje666 schreef op donderdag 27 november 2014 @ 02:12:
[...]

Klopt Lars , maar icm sommige packages is dat gewoon kut , ik wil php5.5 wegens stuk more responsive , echter pakt die spotweb service dat niet..
Die packages zouden iets meer generic qua packages gemaakt moeten worden tevens zou jij als geen ander moeten weten hoeveel tijd ik in het tweaken van mn make.conf e.d. ten behoeve van mn ports heb gestoken..

Als je spotweb ook upgrade (gewoon met portmaster -ad, heb je alles up-to-date) zou het toch gewoon moeten werken?

[FREAKJAM]

FireDrunk schreef op donderdag 27 november 2014 @ 15:29:
[...]


Die directory komt pas, als er daadwerkelijk GPT labels zijn

De disks hebben in ZFSGuru weldegelijk GPT labels, dus vreemd is het wel.

[FireDrunk]

Vreemd, mijn pool is gemaakt onder ZFSguru en heb ik altijd prima kunnen importeren op basis van GPT onder ZoL.

Post de output van "blkid" en "gdisk -l /dev/sd[je drivers]" eens.

[ Voor 23% gewijzigd door FireDrunk op 27-11-2014 16:05 ]

[FREAKJAM]

Hij list de schijven niet onder "blkid". (De entries die hieronder staan betreft de VMWare VHD)

code:

sudo blkid
/dev/sda5: UUID="6f793570-8e09-477a-8472-141857f8289b" TYPE="swap"
/dev/sda1: UUID="6df5db9a-9770-4f00-a7f3-b4c5393cde9a" TYPE="ext4"

code:

maximum@zebian:~$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3CBDF2E0-1EEC-40AA-A732-9EF333D652C9
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533099 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            6144            6145   1024 bytes  A504  SDB-WD-WMC4N0565854

in dmesg komen de schijven ook gewoon voorbij gefietst:

code:

[    1.444058] sd 0:0:0:0: [sdb] Attached SCSI disk
[    1.444076] sd 0:0:1:0: [sdc] Attached SCSI disk
[    1.444689] sd 0:0:2:0: [sdd] Attached SCSI disk
[    1.447167] sd 0:0:4:0: [sdf] Attached SCSI disk
[    1.447547] sd 0:0:3:0: [sde] Attached SCSI disk
[    1.447572] sd 0:0:5:0: [sdg] Attached SCSI disk

edit:
Ik denk dat ik al weet wat het probleem is. Hij blijft een oude hidden pool zien op mijn schijven, ook al heb ik ze geformatteerd. (het id kwam me ook al bekend voor).

code:

   pool: tank
     id: 15167750781093255048
  state: ONLINE
 status: Some supported features are not enabled on the pool.
 action: The pool can be imported using its name or numeric identifier, though
    some features will not be available without an explicit 'zpool upgrade'.
 config:

Ik kan deze pool ook niet importeren, want dan loopt de boel gelijk vast. Urgh.

[ Voor 32% gewijzigd door FREAKJAM op 27-11-2014 16:58 ]

[FireDrunk]

Even een rescue cd zonder zfs booten, en kijken of je dan die entries ziet?

[FREAKJAM]

FireDrunk schreef op donderdag 27 november 2014 @ 17:05:
Even een rescue cd zonder zfs booten, en kijken of je dan die entries ziet?

Ja in een andere VM zie ik ze wel met als label "tank" (naam van mijn oude en waarschijnlijk corrupte pool). Wellicht de schijven eerst formatten naar een willekeurig ander FS? Ik snap niet waarom die oude/corrupte pool op mijn schijven blijft staan.

edit:
Op een VM zonder ZFS ziet hij iig dat er CRC errors zijn op schijf sdc.

Hopelijk kan ik het fixxen, ga nu alle schijven opnieuw formatten.

code:

sudo gdisk /dev/sdc
GPT fdisk (gdisk) version 0.8.8

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!

edit2:

In non-ZFS VM is nu alles okay:

code:

maximum@dubuntu:/dev/disk/by-partlabel$ ls
SDB-WD-WMC4N0565854  SDD-WD-WMC4N0565375  SDF-WD-WMC4N0245360
SDC-WD-WMC4N0328511  SDE-WD-WMC4N0237419  SDG-WD-WMC4N0565098

edit3:
In zowel Ubuntu, Debian als ZFSGuru blijft hij die achterlijke pool zien

[ Voor 51% gewijzigd door FREAKJAM op 27-11-2014 17:22 ]

[duiveltje666]

Compizfox schreef op donderdag 27 november 2014 @ 15:39:
[...]

Als je spotweb ook upgrade (gewoon met portmaster -ad, heb je alles up-to-date) zou het toch gewoon moeten werken?

nee nee , het spotweb deel van die package kan niet installed worden ivm de php-versie mismatch

[Verwijderd]

duiveltje666 schreef op donderdag 27 november 2014 @ 17:50:
[...]

nee nee , het spotweb deel van die package kan niet installed worden ivm de php-versie mismatch

Wat bedoel je nou precies?

Spotweb heeft helemaal geen package en ook geen port. Het wordt los geïnstalleerd door ZFSguru. Dus je PHP versie mismatch bestaat ook niet. Hooguit kan het zijn dat Spotweb niet compatible is met een hogere versie van PHP, dat is iets heel anders.

Voor ports kun je in /etc/make.conf de 'default_versions' instellen, PHP5.6 of Perl5.20 wat je wilt. Dan zullen ports die dit gebruiken ook hun dependency op deze versie van php/perl instellen.

[FireDrunk]

Formatteren helpt niet FreakJam, je zal de hele disk leeg moeten dd-en voordat ZFS geen pool meer ziet. Dit komt omdat ZFS de pool data meerdere keren opslaat op verschillende stukken van de schijf.

[Verwijderd]

Pool importeren en destroyen is de juiste manier, dan kun je de pool enkel zien als je een extra parameter meegeeft om te zoeken naar destroyed pools.

[FireDrunk]

Inderdaad, die was ik nog vergeten!

[FREAKJAM]

Dat is het probleem, ik kan hem niet meer importeren omdat de boel dan crashed

code:

maximum@zubuntu:~$ sudo zpool import
[sudo] password for maximum:
   pool: tank
     id: 15167750781093255048
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank                                          ONLINE
          raidz2-0                                    ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0328511  ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0565375  ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0237419  ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0565854  ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0245360  ONLINE
            ata-WDC_WD30EFRX-68EUZN0_WD-WMC4N0565098  ONLINE
maximum@zubuntu:~$ sudo zpool import -d 15167750781093255048
maximum@zubuntu:~$ zfs list
Unable to open /dev/zfs: Permission denied.
maximum@zubuntu:~$ sudo zfs list
no datasets available
maximum@zubuntu:~$ sudo zpool import -d /dev/disk/by-id/ 15167750781093255048
cannot import 'tank': pool may be in use from other system
use '-f' to import anyway
maximum@zubuntu:~$ sudo zpool import -f -d /dev/disk/by-id/ 15167750781093255048

Hele lange dmesg (scroll naar beneden vanaf de spl error voor de crash)
http://pastebin.com/HF8JYQdE

edit:
fixxed in FreeNAS denk ik! (schijnbaar rewind je de pool naar zijn vorige status met import-fFX en dat deed ie in een paar seconde)

code:

[root@freenas ~]# mkdir -p /tmp/tank

[root@freenas ~]# zpool import -fFX -R /tmp/tank tank                           
[root@freenas ~]# zfs list                                                      
NAME                        USED  AVAIL  REFER  MOUNTPOINT                      
freenas-boot                936M  6.78G    31K  none                            
freenas-boot/ROOT           928M  6.78G    31K  none                            
freenas-boot/ROOT/default   928M  6.78G   928M  legacy                          
freenas-boot/grub          7.77M  6.78G  7.77M  legacy                          
tank                       1.49M  10.5T   304K  /tmp/tank/mnt/tank              
tank/storage                288K  10.5T   288K  /tmp/tank/mnt/tank/storage      
[root@freenas ~]# zpool destroy tank                                            
[root@freenas ~]# zfs list                                                      
NAME                        USED  AVAIL  REFER  MOUNTPOINT                      
freenas-boot                936M  6.78G    31K  none                            
freenas-boot/ROOT           928M  6.78G    31K  none                            
freenas-boot/ROOT/default   928M  6.78G   928M  legacy                          
freenas-boot/grub          7.77M  6.78G  7.77M  legacy

Toen ik toenstraks thuis kwam van me werk was mijn ESXi stick ook nog eens niet meer bootable. Gelukkig had ik nog een backup van de config van ESXi van een paar weken terug. Moest ESXi herinstalleren en config terugzetten met PowerCLI. Leuk weekje zo met al die issues

edit 3:
In Linux ziet het er nu ook weer goed uit

code:

maximum@zubuntu:~$ sudo zpool import
no pools available to import

Na het opnieuw formatten volgens de blog van FireDrunk en een reboot doet /dev/disk/by-partlabel het eindelijk ook.

code:

maximum@zubuntu:/dev/disk$ ls -l /dev/disk/by-partlabel/
total 0
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDB-WD-WMC4N0565854 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDC-WD-WMC4N0328511 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDD-WD-WMC4N0565375 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDE-WD-WMC4N0237419 -> ../../sde1
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDF-WD-WMC4N0245360 -> ../../sdf1
lrwxrwxrwx 1 root root 10 Nov 27 21:45 SDG-WD-WMC4N0565098 -> ../../sdg1

[ Voor 140% gewijzigd door FREAKJAM op 27-11-2014 21:46 ]

[FireDrunk]

Ik kan die crash ook verklaren... Je mountpoints staan namelijk aan... Dus je freebsd rootpool wordt gemount over je linux filesysteem... Dat gaat niet werken...

[FREAKJAM]

Ik ben allang blij dat alles het weer zo goed als doet. Erg dank voor je hulp dan ook. Onder Debian blijven de partlabels moeilijk doen, maar onder Ubuntu draait alles nu in ieder geval.

[FireDrunk]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681809

The partuuid/partlabel rules are after the:
# probe filesystem metadata of disks
KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
line which defines the environment for the rules to work.

Apparently, just moving the partuuid rule to the end fixes this bug.

[FREAKJAM]

FireDrunk schreef op vrijdag 28 november 2014 @ 08:43:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681809


[...]

Minder laconiek zijn zie ik wel weer. Ik had dit artikel gister ook gevonden maar toen ik zag dat de "bug" al twee jaar oud was en dacht ik dat dat de oplossing niet kon zijn. Ik heb de partlabel rules gemoved naar het einde en nu werkt het inderdaad.

Verder het volgende veranderd in /etc/default/zfs en nu auto mount hij ook mijn pool in Debian.

code:

# Sould we use '-d /dev/disk/by-id' when importing pool.
# This is recomended, but the default 'no' uses the cache
# file
USE_DISK_BY_ID='no'

[FireDrunk]

De allereerste default van ZFS is volgens mij ruw /dev/ gebruiken, dan krijg je dus dat ZFS je pool gaat importeren op /dev/sd[a-z]. Dat wil je *echt* niet.

Daarna probeert de ZFSonLinux implementatie dus by-id, wat ook niet mijn voorkeur heeft.

Maar zoals je in mijn andere blogpost kan lezen, is

zpool import -d /dev/disk/by-partlabel/ 

eigenlijk altijd de betere optie.

[HyperBart]

FireDrunk schreef op vrijdag 28 november 2014 @ 09:36:
De allereerste default van ZFS is volgens mij ruw /dev/ gebruiken, dan krijg je dus dat ZFS je pool gaat importeren op /dev/sd[a-z]. Dat wil je *echt* niet.

Gaat toch goed . Ergens ervaring mee FD?

[justice strike]

heeft iemand een mening over ecc voor zfs? Ik snap dat het de zwakste schakel is, maar sommige discussies gaan volledig voorbij aan de toegevoegde waarde tov het geld wat je ervoor opzij moet leggen.

[FREAKJAM]

justice strike schreef op vrijdag 28 november 2014 @ 12:40:
heeft iemand een mening over ecc voor zfs? Ik snap dat het de zwakste schakel is, maar sommige discussies gaan volledig voorbij aan de toegevoegde waarde tov het geld wat je ervoor opzij moet leggen.

Ik denk dat er uitgebreid is gesproken over ECC in dit topic. In het topic player-x in "Het grote DIY RAID NAS topic deel 3" was er vrij recent nog een aardige discussie over ECC. Er komt ooit nog eens een apart ECC/non-ECC topic, maar ik denk dat er voor nu al genoeg te vinden is in dit topic en eerder genoemd topic.

Ik heb zelf trouwens ECC RAM in mijn setup.

[ Voor 19% gewijzigd door FREAKJAM op 28-11-2014 13:02 ]

[HyperBart]

En CiPHER heeft daar nog een mening over ivm het feit dat je dan ECC beter op je clients doet dan op je server, maar toegevoegde waarde was voor mij ook ergens een slotsom dat het sop de kolen niet waard is.

[FireDrunk]

De meningen zijn erover verdeeld, en er is niet 1 simpel antwoord te geven anders dan:"It depends..." en laten we het daar alsjeblieft bij houden, want anders gaan we de discussie voor de 100ste keer opnieuw voeren

[justice strike]

Dan maar een andere vraag. Ik zie op de intel site dat er maar een aantal chipsets ecc ondersteunen.. op de pricewatch zijn dan alleen maar moederborden met socket 2011. Dan vind ik het vreemd dat er celeron cpu's zijn die ecc ondersteunen, hebben die dan geen specifiek mobo nodig?

enfin maakt verder niets uit. Ik begin me zo langzamer hand ook af te vragen of een server met vt-d die een paar vm's draait en een paar thin clients niet vele malen goedkoper is dan overal een pc neer te zetten, maar dat is een discussie voor een andere keer.

[Pantagruel]

FireDrunk schreef op vrijdag 28 november 2014 @ 15:07:
De meningen zijn erover verdeeld, en er is niet 1 simpel antwoord te geven anders dan:"It depends..." en laten we het daar alsjeblieft bij houden, want anders gaan we de discussie voor de 100ste keer opnieuw voeren

Nou eigenlijk ben ik van mening dat ................ we allemaal volwassen genoeg moeten kunnen zijn om elkanders keuzes te accepteren en streven naar een gereguleerde discussie die constructief is. Aan bashen hebben we niet zo veel.

justice strike schreef op vrijdag 28 november 2014 @ 16:13:
Dan maar een andere vraag. Ik zie op de intel site dat er maar een aantal chipsets ecc ondersteunen.. op de pricewatch zijn dan alleen maar moederborden met socket 2011. Dan vind ik het vreemd dat er celeron cpu's zijn die ecc ondersteunen, hebben die dan geen specifiek mobo nodig?

enfin maakt verder niets uit. Ik begin me zo langzamer hand ook af te vragen of een server met vt-d die een paar vm's draait en een paar thin clients niet vele malen goedkoper is dan overal een pc neer te zetten, maar dat is een discussie voor een andere keer.

Intel boards met ECC ondersteuning heb je ook in socket 1150/1155 formaat (C2xx chipset reeks), de ondersteuning is jammerlijk wel tot 32 GB beperkt (voor zover dat een probleem is.

[justice strike]

dat zijn bordjes die behoorlijk aan de prijs zijn.

[FireDrunk]

Klopt, ECC (en dus eigenlijk, enterprise grade hardware) is duur(der).

[justice strike]

het is bijna goedkoper om twee keer zoveel geheugen te kopen en een 'raid' array in je geheugen te programmeren

[Bigs]

justice strike schreef op vrijdag 28 november 2014 @ 17:30:
het is bijna goedkoper om twee keer zoveel geheugen te kopen en een 'raid' array in je geheugen te programmeren

Klopt maar daarvoor moet je een server moederbord hebben (die hebben dat soort functies) en dan heb je sowieso ECC geheugen

[justice strike]

Bigs schreef op vrijdag 28 november 2014 @ 17:35:
[...]


Klopt maar daarvoor moet je een server moederbord hebben (die hebben dat soort functies) en dan heb je sowieso ECC geheugen

of je maakt een software raid constructie (moet niet al te moeilijk zijn, ipv 1 keer geheugen alloceren doe je het 2 keer.)

[Kortfragje]

Je kan ook naar AMD kijken. Ik heb zelf een
Asus M5A97 R2.0 met Athlon II X3 450 en 16 GB geheugen.

Goed betaalbaar en MET ECC.

[justice strike]

Kortfragje schreef op vrijdag 28 november 2014 @ 17:49:
Je kan ook naar AMD kijken. Ik heb zelf een
Asus M5A97 R2.0 met Athlon II X3 450 en 16 GB geheugen.

Goed betaalbaar en MET ECC.

Ik denk dat ik tegen die tijd nog wel een keertje zal kijken. AMD is niet echt energie zuinig, maar die avoton bordjes zijn dan wel weer interessant.

[FireDrunk]

justice strike schreef op vrijdag 28 november 2014 @ 17:38:
[...]

of je maakt een software raid constructie (moet niet al te moeilijk zijn, ipv 1 keer geheugen alloceren doe je het 2 keer.)

Dat helpt niet tegen bitflips...

[justice strike]

FireDrunk schreef op vrijdag 28 november 2014 @ 18:00:
[...]

Dat helpt niet tegen bitflips...

nee die bitflip zal nog wel voorkomen, maar de kans dat 2 bitflips op dezelfde gespiegelde bit zich voor zal doen maakt in iedergeval dat het gedetecteerd kan worden.

[Bigs]

justice strike schreef op vrijdag 28 november 2014 @ 17:38:
[...]

of je maakt een software raid constructie (moet niet al te moeilijk zijn, ipv 1 keer geheugen alloceren doe je het 2 keer.)

En daarmee halveer je de geheugenbandbreedtte.. nu ben je gewoon vreemde oplossingen aan het verzinnen voor een probleem dat allang is opgelost (door middel van ECC geheugen evt met rank sparing of memory mirroring). Als ECC geheugen buiten je budget ligt dan zul je voor niet-ECC geheugen moeten gaan.

[Verwijderd]

Uiteindelijk is het beste als ECC in software kan worden uitgevoerd. Dus dat je alle DRAM chips individueel kunt aanspreken en je eigen gewenst niveau van bescherming, zoals 3-voudige parity protection op 16 chips of 32 chips. Dan heb je veel betere bescherming dan ECC nu met enkelvoudige (correctie-)bescherming, maar met minimale overhead en vrijwel geen prestatieverlies.

Probleem is natuurlijk dat zoiets niet compatible zal zijn met legacy operating systems. En om die reden wordt vanalles geëmuleerd en wordt innovatie afgeremd.

Hetzelfde idee is ook mogelijk met SSDs; FreeBSD heeft bijvoorbeeld een NAND driver die eigenlijk de functie overneemt van de SSD controller. Dus de ruwe NAND aanspreken, zelf de mapping tables en parity uitvoeren, enzovoorts. Eigenlijk superieur.

De algemene trend is ook dat iets begint met een hardware implementatie en uiteindelijk in geavanceerdere software terecht komt. Softwareimplementaties zijn in principe superieur aan hardwareimplementaties, door de flexibiliteit en mogelijkheid om veranderingen uit te voeren en te testen. Veel hardware draaien op een belangrijk gedeelte op software (firmware). Zelfs je CPU gebruikt firmware om de microcode te genereren uit machinecode.

[ Voor 3% gewijzigd door Verwijderd op 28-11-2014 22:22 ]

[justice strike]

Bigs schreef op vrijdag 28 november 2014 @ 22:16:
[...]


En daarmee halveer je de geheugenbandbreedtte.. nu ben je gewoon vreemde oplossingen aan het verzinnen voor een probleem dat allang is opgelost (door middel van ECC geheugen evt met rank sparing of memory mirroring). Als ECC geheugen buiten je budget ligt dan zul je voor niet-ECC geheugen moeten gaan.

ik zei al eerder dat het bijna goedkoper is om 2 keer zoveel geheugen te kopen en dat te gebruiken dan ecc te kopen. Wat Cipher hierboven aangeeft is ook precies wat ik bedoel. Wat je in hardware kunt doen, kun je ook in software doen eigenlijk.

[Kortfragje]

Nice, ik zeg Romeo Delta..

[FireDrunk]

Nee, dat kan allemaal niet! ECC en checksum controles moeten in hardware gebeuren. Wat namelijk als er een bitflip gebeurt in de code die de checksum controlleert? Dan ga je nat... Je moet goed bedenken dat de code die jullie nu beschrijven ook in datzelfde geheugen zit. Dat gaat dus nooit werken. En al helemaal als je begrijpt hoe CPU pointers en instructies werken, snap je dat ecc tussendoor onnoemelijk veel vertraging zou opleveren. Dan praat je echt in de orde van tientallen procenten denk ik.

[Q]

Iemand heeft ooit eens een poging gedaan.

http://pdos.csail.mit.edu.../softecc_ddopson-meng.pdf

Read section 5.2 of that thesis, particularly this quote from 5.2.2:

"For random word writes, this implies that SoftECC will need an order of
magnitude more compute time than the user-mode code"

Basically, on every single memory page that gets dirtied, we have to then
re-checksum the page (blowing away cache lines in the process). If you want
to get a feel for it, find the kernel code that recognizes that a page is
dirtied, and just add a few lines there:

int foo = 0, i;
for (i=0;i++;<1024) { // adjust for non-4K pages
foo ^= *(page+i);
}

and see how much your system crawls.

Personally, I'd recommend just shelling out the bucks for hardware ECC if
the reliability matters.

https://groups.google.com.../Qunj-mrWsMs/dw1_4tpagsYJ

[FireDrunk]

I rest my case

[Verwijderd]

FireDrunk schreef op zaterdag 29 november 2014 @ 08:09:
Nee, dat kan allemaal niet! ECC en checksum controles moeten in hardware gebeuren. Wat namelijk als er een bitflip gebeurt in de code die de checksum controlleert?

Dat geldt toch evengoed voor de firmware die in hardware zit? Wat als daar een fout in ontstaat, zelfde effect.

Wat als de firmware van je CPU een fout maakt; of de ECC algoritmes zelf, de onboard SRAM caches in de SSD controller? Enzovoorts. Niets is 100% betrouwbaar.

SSDs gebruiken ook een DRAM chip; is deze 100% betrouwbaar? ECC vereist een extra chip terwijl SSDs er maar één gebruiken. Zelfde verhaal voor hardeschijven die hebben ook één DRAM chip ipv minimaal twee voor error correctie.

Je systeem RAM is natuurlijk veel groter. En wat Q hierboven zegt is natuurlijk niet wat ik bedoel. Dat is gewoon het systeem RAM als geheel aanspreken en niet via software-algoritmen de DRAM chips individueel aanspreken. Daar zijn ook hardwarematige veranderingen voor nodig.

Hoe ik het voorstel is dat je een 'BIOS' zou hebben die de systeem RAM beheert en waarmee je dus zou kunnen instellen hoe sterk je parity bescherming voor RAM zou moeten zijn. Sterkere bescherming betekent minder beschikbaar RAM en iets lagere performance, net als RAID-Z1/2/3 dat doet voor je disks.

[Bigs]

Verwijderd schreef op zaterdag 29 november 2014 @ 12:31:
[...]

Dat geldt toch evengoed voor de firmware die in hardware zit? Wat als daar een fout in ontstaat, zelfde effect.

Wat als de firmware van je CPU een fout maakt; of de ECC algoritmes zelf, de onboard SRAM caches in de SSD controller? Enzovoorts. Niets is 100% betrouwbaar.

SSDs gebruiken ook een DRAM chip; is deze 100% betrouwbaar? ECC vereist een extra chip terwijl SSDs er maar één gebruiken. Zelfde verhaal voor hardeschijven die hebben ook één DRAM chip ipv minimaal twee voor error correctie.

Je systeem RAM is natuurlijk veel groter. En wat Q hierboven zegt is natuurlijk niet wat ik bedoel. Dat is gewoon het systeem RAM als geheel aanspreken en niet via software-algoritmen de DRAM chips individueel aanspreken. Daar zijn ook hardwarematige veranderingen voor nodig.

Hoe ik het voorstel is dat je een 'BIOS' zou hebben die de systeem RAM beheert en waarmee je dus zou kunnen instellen hoe sterk je parity bescherming voor RAM zou moeten zijn. Sterkere bescherming betekent minder beschikbaar RAM en iets lagere performance, net als RAID-Z1/2/3 dat doet voor je disks.

Decennia van enterprise-grade x86 hardware zeggen dat de huidige aanpak uitstekend werkt. In servers werkt het zo dat wanneer een ECC DIMM meerdere herstelbare fouten aangeeft de data wordt overgeplaatst naar een hot spare en de defecte DIMM buiten dienst wordt gesteld. Dit wordt door de processor(s) afgehandeld zonder tussenkomst van het OS, voordat de DIMM errors detecteert die hij niet meer kan herstellen. Waarom zou je dit opnieuw gaan uitvinden in software? Zoals Q hierboven al aangeeft zouden de prestaties daarvan vreselijk zijn.

[Verwijderd]

ECC zelf kan slechts enkele bitfouten corrigeren en dubbele bitfouten detecteren, voor zover ik weet. Met meervoudige parity correction kun je geheugen een veel hoger niveau van bescherming geven. Cruciaal voor de volgende stap waarin je computers vrijwel 100% betrouwbaar maakt.

De performance overhead kan minimaal zijn als je niet aan legacy implementaties doet maar de hardware en software van de grond af aan bouwt, iets wat vrijwel nooit gebeurt in x86-land omdat alles compatible moet blijven en je vieze hacks krijgt waarbij legacy op legacy wordt gestapeld.

Bovendien is de performance niet meer zo relevant zodra je DRAM chips individueel kunt aanspreken. Want dan heb je het ook over een 16 tot 32 keer hogere geheugenbandbreedte. Al zou je het door de helft moeten delen, zit je nog steeds veel hoger dan nu het geval is.

De problemen zijn vooral dat er grote wijzigingen aan zowel de hardware maar vooral de software moeten gebeuren voordat dit gaat werken. Windows draaien op dergelijke hardware is dan vrijwel uitgesloten. En in de praktijk betekent dit dat het er nooit van zal komen. Alleen legacy oplossingen overwinnen de markt.

[IceTeaGX]

Hardware implementaties dienen niet van firmware voorzien te worden. Dat is pure gate logic en klaar. Alles waar firmware aan te pas komt, is eigenlijk een partiële software implementatie met ergens een microcontroller of dedicated CPU.

ECC kan enkele bitfouten corrigeren, en meerdere bitfouten detecteren. Enkel als het aantal bitfouten exact voldoende is voor de CRC terug rond te krijgen zal het niet gedetecteerd worden. Daarbij verkleint de kans exponentieel dat meerdere bitfouten gelijktijdig zullen voorkomen.

Software zal altijd ordes van magnitude trager zijn dan hardware. Zie naar bitcoin mining:
Software op CPU <<< Software op GPU <<< FPGA <<< ASIC
Het voordeel is uiteraard flexibiliteit, De CPU kan allerhande berekeningen uitvoeren, de ASIC niet.

[Q]

Ik denk dat IceTeaGX precies het punt te pakken heeft (pure gate logic en de snelheid). Daarom draaien we op CPUs en niet FPGAs. Daarom gebruik je custom hardware als je snelheid en betrouwbaarheid wilt.

De kans dat er met ECC een bitfout optreedt die een collission veroorzaakt is waarschijnlijk zo waanzinnig klein dat je die kunt verwaarlozen. ECC bescherming is niet 100% perfect, maar effectief gaat het om een afrondingsfout. De hele IT wereld draait er op en het heeft zich 100% bewezen.

ZFS voor je RAM lijkt mij een verspilling van resources. Welk probleem probeer je hiermee op te lossen?

Enterprise storage schijven hebben in tegenstelling tot de goedkopere desktop hardware die wij toepassen als consumenten ECC geheugen voor hun cache. Enterprise drives hebben vaak ook een afwijkend sector formaat (iets groter) waarin checksums over de sector wordt opgeslagen. Juist voor ons consumenten is ZFS daarom nog relevanter.

Ik begrijp het concept dat je de componenten zo dom en goedkoop mogelijk maakt en alles in software afhandelt. Dan heb je inderdaad alles tot in het kleinste detail onder controle en de flexibiliteit is enorm.
Maar wat voor flexibiliteit wil je en heb je nodig waarvoor?

[FireDrunk]

Goed punt, ik ben liever afhankelijk van Intel die 1miljoen euro investeert in verbetering van ECC technieken dan dat een paar open source programmeurs met SoftECC aan de slag gaan... Misschien minder transperant maar meer getest en proven technology.

[justice strike]

Volgens mij werkt ecc nog steeds hetzelfde als dat 10 jaar geleden werkte. De techniek bestaat al decennia en is eigenlijk niet meer verbeterd sindsdien.Overigens was die techniek ook ontwikkeld in een tijd dat hardware veel minder snel en betrouwbaar was als nu.

Zou je dit allemaal opnieuw willen bouwen dan zou het allemaal in software gebeuren. Het is eigenlijk dezelfde discussie als Monolithic vs Microkernel discussie. Performance is tegenwoordig vaak geen argument meer om iets niet in software te implementeren. Anders zouden we vandaag de dag niet over vm's en interpreted code meer praten en alles nog in C implementeren. Goed voorbeeld hiervan is zfs zelf overigens. De geheugen requirements waren bij introductie nogal fors. Dat is nu al een stuk minder een probleem. In 5 tot 10 jaar is het echt een non-issue, wat je overhoud is wel een robuust systeem.

enfin, ik snap waarom mensen deze discussie niet willen oprakelen, het is voornamelijk emotie wat ik hier proef. Excuses voor het oprakelen.

[ Voor 42% gewijzigd door justice strike op 01-12-2014 14:39 ]

[FireDrunk]

Oh, ik vind het best een boeiende discussie om inhoudelijk over ECC te praten hoor, zolang we het daar bij houden.

Ik ben het niet helemaal met je eens, want de hoeveelheid ECC is toch wel belangrijk voor de hoeveelheid bitflips die opgelost kunnen worden.

In principe is ECC toegepast in RAM in staat om 1 bit flip te corrigeren, en meerdere te detecteren.
Maar als je kijkt naar de Flash (SSD) wereld, kunnen ze daar meerdere bitflips herstellen.

Dit zou impliceren dat ook in RAM land ze potentieel meer ECC bytes zouden kunnen implementeren in de sticks, waardoor multiple bit flips oplosbaar zouden worden.

Of dit betaalbaar / haalbaar is weet ik niet.

Bovendien zijn er meerdere ECC algoritmes, het is niet maar 1 type checksum volgens mij... Er zijn meerdere wegen die naar rome leiden...

Checksums hebben een collision kans, en ook daar zijn weer vage algoritmes voor, volgens mij...

[ Voor 15% gewijzigd door FireDrunk op 01-12-2014 15:33 ]

[justice strike]

FireDrunk schreef op maandag 01 december 2014 @ 15:32:
Oh, ik vind het best een boeiende discussie om inhoudelijk over ECC te praten hoor, zolang we het daar bij houden.

Ik ben het niet helemaal met je eens, want de hoeveelheid ECC is toch wel belangrijk voor de hoeveelheid bitflips die opgelost kunnen worden.

In principe is ECC toegepast in RAM in staat om 1 bit flip te corrigeren, en meerdere te detecteren.
Maar als je kijkt naar de Flash (SSD) wereld, kunnen ze daar meerdere bitflips herstellen.

Dit zou impliceren dat ook in RAM land ze potentieel meer ECC bytes zouden kunnen implementeren in de sticks, waardoor multiple bit flips oplosbaar zouden worden.

Of dit betaalbaar / haalbaar is weet ik niet.

Bovendien zijn er meerdere ECC algoritmes, het is niet maar 1 type checksum volgens mij... Er zijn meerdere wegen die naar rome leiden...

Checksums hebben een collision kans, en ook daar zijn weer vage algoritmes voor, volgens mij...

Als we het hebben over ecc ram dan is er maar 1 implementatie, dat is de hamming code. Ik heb ook niet het idee dat die binnenkort gaat veranderen. Dat er andere vormen zijn en dat die toegepast worden in ssd's dat begrijp ik, maar dat is ook een beetje smokkelen want dat wordt gewoon in software geimplementeerd. Dat is overigens zodanig complex dat ze dat nooit in een hardware implementatie gaan gieten. De kans dat je een fout maakt en niet kunt corrigeren is immens.

Als je het hebt over software implementatie dan zijn er meerdere oplossingen mogelijk. Softecc is misschien niet eens de beste oplossing. Duplication en register rotation zijn al zaken die een stuk helpen. Leuk feitje. met 50% duplication vang je al 85% van de fouten af met slechts 28% impact of (CPU) performance.

Dat is overigens iets wat zich door blijft ontwikkelen. Iets wat je met ecc geheugen niet echt kunt zeggen.

leuke link:
http://en.wikipedia.org/wiki/Immunity-aware_programming

[ Voor 8% gewijzigd door justice strike op 01-12-2014 18:02 ]

[Verwijderd]

Modbreak:

Je eigen V&A-advertentie aanprijzen op het forum is ongewenst. Wel kun je een link naar je advertentie in je signature plaatsen. Dat is wel toegestaan.

[ Voor 84% gewijzigd door Verwijderd op 02-12-2014 16:52 ]

[matty___]

De vraag is of deze wel met ZFS samen werkt en voor minder heb je een IBM SAS kaartje

[ Voor 57% gewijzigd door Verwijderd op 02-12-2014 16:52 ]

[CurlyMo]

For whom it may concern

Afgelopen week heb ik mijn offsite backup in werking gezet. Zoals eerder aangegeven ben ik een tijd terug aan het experimenteren geweest met ZFS op ARM. Op dit moment draait het volgende systeem bij een familielid als offsite backup:

• Hummingboard Carrier Base icm een MicroSOM i2eX
• Debian met een custom kernel incl. ZFS
• WD Green 1TB via USB 3

Host upload is hier 50mbit
Client download snelheid ligt rond de 30mbit

De gemiddelde zfs send/receive snelheid is zo'n 2.5M/s

Normaal gesproken duurt het bijwerken van de backup niet langer dan 5min. In het extreemste geval zal hij 1 uur bezig zijn. Denk aan nieuwe vakantiefoto's.

Maandelijkse scrub duurt wel lang met ongeveer 44 uur voor 650GB met een snelheid van +/- 3.82M/s. Lokale backup en mijn data pool laat ik dus elke week scrubben. Deze offsite backup schijf maandelijks.

Stroomverbruik ligt rond de 4w continue.

[DRAFTER86]

CurlyMo schreef op dinsdag 02 december 2014 @ 18:38:
For whom it may concern

Afgelopen week heb ik mijn offsite backup in werking gezet. Zoals eerder aangegeven ben ik een tijd terug aan het experimenteren geweest met ZFS op ARM. Op dit moment draait het volgende systeem bij een familielid als offsite backup:

• Hummingboard Carrier Base icm een MicroSOM i2eX
• Debian met een custom kernel incl. ZFS
• WD Green 1TB via USB 3

Host upload is hier 50mbit
Client download snelheid ligt rond de 30mbit

De gemiddelde zfs send/receive snelheid is zo'n 2.5M/s

Normaal gesproken duurt het bijwerken van de backup niet langer dan 5min. In het extreemste geval zal hij 1 uur bezig zijn. Denk aan nieuwe vakantiefoto's.

Maandelijkse scrub duurt wel lang met ongeveer 44 uur voor 650GB met een snelheid van +/- 3.82M/s. Lokale backup en mijn data pool laat ik dus elke week scrubben. Deze offsite backup schijf maandelijks.

Stroomverbruik ligt rond de 4w continue.

Zou je iets kunnen uitweiden over hoe je dit doet qua snapshots?
Zelf stuur ik incrementele daily en monthly snapshots naar een offsite backup-buddy, maar ik zit nog wat te prutsen met het betrouwbaar versturen van incrementele snapshots...
Wat m.i. het mooiste zou zijn is als je een snapshot over ssh kunt send/receiven, en dat ZFS zelf uitzoekt welke incrementele 'from' -snapshot aanwezig is op de ontvanger en de minste traffic kost.
Maar dat lijkt niet echt te kunnen...

[Pantagruel]

DRAFTER86 schreef op dinsdag 02 december 2014 @ 18:56:
[...]


Zou je iets kunnen uitweiden over hoe je dit doet qua snapshots?
Zelf stuur ik incrementele daily en monthly snapshots naar een offsite backup-buddy, maar ik zit nog wat te prutsen met het betrouwbaar versturen van incrementele snapshots...
Wat m.i. het mooiste zou zijn is als je een snapshot over ssh kunt send/receiven, en dat ZFS zelf uitzoekt welke incrementele 'from' -snapshot aanwezig is op de ontvanger en de minste traffic kost.
Maar dat lijkt niet echt te kunnen...

ZFS send/receive over ssh is geen probleem, geen idee of er automagisch het incremental 'from date' bepaald kan worden. Ik trek doorgaans een snapshot list van de ontvangen bak met de backup pool en van de send target, maak een diff van de twee txt files en deze dient als input voor de zfs send/receive loop.
Wellicht ietwat ruw om de randjes, maar t werkt.

[DRAFTER86]

Pantagruel schreef op dinsdag 02 december 2014 @ 19:05:
[...]


ZFS send/receive over ssh is geen probleem, geen idee of er automagisch het incremental 'from date' bepaald kan worden. Ik trek doorgaans een snapshot list van de ontvangen bak met de backup pool en van de send target, maak een diff van de twee txt files en deze dient als input voor de zfs send/receive loop.
Wellicht ietwat ruw om de randjes, maar t werkt.

Maar doe je dat dan incrementeel?
Waar het volgens mij bij misgaat (maar ik moet dit nog eens goed testen), is dat een incrementele send alleen vanaf de most recent snapshot op de ontvanger kan.
Dit betekent effectief dat als je snapshots incrementeel wil versturen, je ze op volgorde van aanmaken moet versturen.
Ik heb nu een script dat eerst checkt of er een daily is die verstuurd moet worden (ik hou zelf bij wat de laatste is die ik verstuurd heb), daarna checkt hij of er een monthly is die verstuurd moet worden.
Als nu die monthly toevallig 1 seconde (door zfs-auto-backup) eerder gemaakt is dan de daily, dan kan ik die monthly niet versturen met de daily als incrementele from-snapshot (de dailyis later gemaakt dan de monthly), maar ook niet met de vorige (een dag oudere) daily als from, omdat dat niet de meest recente snapshot op de ontvanger is...
Goed, ik heb dit nog niet voldoende gedebugged, maar mijn vermoeden is dat dat het probleem is

[CurlyMo]

Dit is wat ik heb geschreven voor dit doeleind. Als je het via SSH wil doen, dan plak je dit commando voor al je commando's die je op je offsite backup pool wilt doen.

code:

ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null x.x.x.x

Authenticatie wordt geregeld via SSH keys.

Bash:

#!/usr/bin/env bash

ERROR=0
DESTINATION="backup";

round()
{
echo $(printf %.$2f $(echo "scale=$2;(((10^$2)*$1)+0.5)/(10^$2)" | bc))
};

MINSPACE=$(($SPACETOTAL-$(round $SPACETOTAL*0.1 0)));
MINSNAP=5;

FOLDERS=(
"data/users/shared/folder"
"data/users/user1/folder"
"data/users/user2/folder"
"data/wwwroot"
"data/mysql"
"rpool"
);

SNAPSHOTS=($(zfs list -t snapshot -o name -H -s creation -r $DESTINATION));
DISKSPACE=($(zfs list -o used,avail -Hp $DESTINATION));
SPACETOTAL=$((${DISKSPACE[0]}+${DISKSPACE[1]}));
SPACEUSED=${DISKSPACE[0]};
SPACEAVAIL=${DISKSPACE[1]};
SPACECAP=$(($(($SPACEAVAIL*100))/$SPACETOTAL));
TMP=$(echo ${SNAPSHOTS[@]} | sed -e 's/\ /\\n/g');
FS=$(echo -e "$TMP" | cut -f1 -d"@" | sort | uniq);
NRSNAP=$(echo -e "$TMP" | cut -f2 -d"@" | sort | uniq | wc -l);
REMOVED=1;

while [ $SPACEUSED -gt $MINSPACE ] && [ $REMOVED -eq 1 ]; do
    REMOVED=0
    TMP=$(echo ${SNAPSHOTS[@]} | sed -e 's/\ /\\n/g');
    for F in ${FS[@]}; do
        NRSNAP=$(echo -e "$TMP" | grep $F | cut -f2 -d"@" | sort | uniq | wc -l);
        S=$(echo -e "$TMP" | grep $F | sort | uniq | head -n 1);
        if [ $NRSNAP -ge $MINSNAP ]; then
            echo "zfs destroy $S"
            zfs destroy $S
            REMOVED=1
            SNAPSHOTS=(${SNAPSHOTS[@]/$S})
            FS=(${FS[@]/$F})
            if [ ${#FS[@]} -eq 0 ]; then
                FS=$(echo -e "$TMP" | cut -f1 -d"@" | sort | uniq);
            fi
            break;
        fi
    done

    sleep 1;

    DISKSPACE=($(zfs list -o used,avail -Hp $DESTINATION));
    SPACETOTAL=$((${DISKSPACE[0]}+${DISKSPACE[1]}));
    SPACEUSED=${DISKSPACE[0]};
    SPACEAVAIL=${DISKSPACE[1]};
    SPACECAP=$(($(($SPACEAVAIL*100))/$SPACETOTAL));
done

if [ $SPACEUSED -gt $MINSPACE ]; then
    echo "Not enough diskspace on $DESTINATION pool" 1>&2   
fi

zfs list $DESTINATION 1>/dev/null 2>/dev/null || ERROR=1;

if [ $ERROR -eq 1 ]; then
    echo "Destination doesn't exists";
    exit;
fi

BACKUP=$(zfs list -o name -r -t snapshot $DESTINATION)
ERROR=0;
NEWLINE=$'\n';

DESTROOT=$(dirname $DESTINATION);

if [ $DESTROOT == "." ]; then
    DESTROOT=$DESTINATION;
fi

for F in ${FOLDERS[@]}; do

    ORIROOT=${F%%/*};
    ORIFS=${F#*/};
    DATA=$(zfs list -o name -r -t snapshot $ORIROOT 2>/dev/null)
    if [ $? -eq 1 ]; then
        echo "Origin $F doesn't exists";
        continue;
    fi

    LASTORISNAP="";
    LASTDESTSNAP="";
    FIRSTORISNAP="";
    FIRSTDESTSNAP="";
    ORISNAPEXISTS=0;

    for D in ${BACKUP[@]}; do
        ROOT=${D%%@*}
        SNAP=${D##*@}
        if [ "$ROOT" == "$DESTINATION/$ORIFS" ]; then
            if [ -z $FIRSTDESTSNAP ]; then
                FIRSTDESTSNAP=$SNAP;
            fi
            LASTDESTSNAP=$SNAP;
        fi
    done
    for D in ${DATA[@]}; do
        ROOT=${D%%@*}
        SNAP=${D##*@}
        if [ "$ROOT" == "$F" ]; then
            if [[ "$LASTDESTSNAP" =~ "$SNAP" ]]; then
                ORISNAPEXISTS=1
            fi
            if [ -z $FIRSTORISNAP ]; then
                FIRSTORISNAP=$SNAP;
            fi
            LASTORISNAP=$SNAP;
        fi
    done

    if [ $ORISNAPEXISTS -eq 1 ]; then
        if [ $LASTORISNAP = $LASTDESTSNAP ]; then
            echo "$F already up-to-date on $DESTINATION";
        else
            echo "zfs send -RI $F@$LASTDESTSNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT"
            zfs send -RI $F@$LASTDESTSNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT
        fi
    else
         if [ ! -z $LASTDESTSNAP ]; then
             echo "$F already has snapshots on $DESTINATION, but none of them matches to an existing snapshot on $ORIGIN";
         else
            echo "zfs send -R $F@$FIRSTORISNAP | zfs receive -Fdvu $DESTROOT"
            zfs send -R $F@$FIRSTORISNAP | zfs receive -Fdvu $DESTROOT
            if [ $FIRSTORISNAP != $LASTORISNAP ]; then
                echo "zfs send -RI $F@$FIRSTORISNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT"
                zfs send -RI $F@$FIRSTORISNAP $F@$LASTORISNAP | zfs receive -dvu $DESTROOT
            fi
        fi
    fi
done

[Pantagruel]

CurlyMo schreef op dinsdag 02 december 2014 @ 20:12:
Dit is wat ik heb geschreven voor dit doeleind. Als je het via SSH wil doen, dan plak je dit commando voor al je commando's die je op je offsite backup pool wilt doen.

code:

ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null x.x.x.x

Authenticatie wordt geregeld via SSH keys.

Bash:

....

Damn, ik heb echt een houtje-touwtje script

[Kortfragje]

CurlyMo schreef op dinsdag 02 december 2014 @ 20:12:
Dit is wat ik heb geschreven voor dit doeleind. Als je het via SSH wil doen, dan plak je dit commando voor al je commando's die je op je offsite backup pool wilt doen.

code:

ssh -q -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null x.x.x.x

Authenticatie wordt geregeld via SSH keys.

Bash:

...

Awesome! Is kijken of ik dit aan kan passen Beter goed gejat dan slecht bedacht...

[Bigs]

Vanwaar het advies om host key checking volledig uit te schakelen, CurlyMo?

[FireDrunk]

Hostkey is toch alleen maar voor man-in-the-middle?

[CurlyMo]

Ik wil het risico niet lopen dat mijn backups falen op een veranderde hostkey.

[Bigs]

Ok wij gebruiken wel hostkeys zodat we juist opmerken als er onverwacht iets wijzigt, bijvoorbeeld dat je door een DNS wijziging ineens de verkeerde server aan het backuppen bent. Backups worden gemonitored via Zabbix dus als er een niet lukt dan weten we dat gelijk.

[CurlyMo]

Het backup script draait op de server zelf dus de verkeerde server backuppen zal niet snel gebeuren

De scrub heeft uiteindelijk 32h59m geduurd voor 667G

[ Voor 25% gewijzigd door CurlyMo op 03-12-2014 19:21 ]

[Compizfox]

code:

ahcich3: Timeout on slot 27 port 0
ahcich3: is 00000000 cs 00000000 ss 08000000 rs 08000000 tfd 40 serr 00000000 cmd 0000fb17
(ada3:ahcich3:0:0:0): READ_FPDMA_QUEUED. ACB: 60 08 d8 62 5b 40 01 00 00 00 00 00
(ada3:ahcich3:0:0:0): CAM status: Command timeout
(ada3:ahcich3:0:0:0): Retrying command
ahcich3: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich3: Timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 00000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich3:0:0:0): CAM status: Command timeout
(aprobe0:ahcich3:0:0:0): Error 5, Retry was blocked
ahcich3: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich3: Timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 00000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(aprobe0:ahcich3:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich3:0:0:0): CAM status: Command timeout
(aprobe0:ahcich3:0:0:0): Error 5, Retry was blocked
ada3 at ahcich3 bus 0 scbus6 target 0 lun 0
ada3: <M4-CT128M4SSD2 070H> s/n 00000000112603132291 detached
ahcich3: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich3: Timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 00000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(ada3:ahcich3:0:0:0): SETFEATURES ENABLE RCACHE. ACB: ef aa 00 00 00 40 00 00 00 00 00 00
(ada3:ahcich3:0:0:0): CAM status: Command timeout
(ada3:ahcich3:0:0:0): Error 5, Periph was invalidated
ahcich3: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich3: Poll timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 00000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(aprobe0:ahcich3:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe0:ahcich3:0:0:0): CAM status: Command timeout
(aprobe0:ahcich3:0:0:0): Error 5, Retries exhausted
ahcich3: Timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 08000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(ada3:ahcich3:0:0:0): READ_FPDMA_QUEUED. ACB: 60 08 d8 62 5b 40 01 00 00 00 00 00
(ada3:ahcich3:0:0:0): CAM status: Command timeout
(ada3:ahcich3:0:0:0): Error 5, Periph was invalidated
(ada3:ahcich3:0:0:0): Periph destroyed
ahcich3: AHCI reset: device not ready after 31000ms (tfd = 00000080)
ahcich3: Poll timeout on slot 27 port 0
ahcich3: is 00000000 cs 08000000 ss 00000000 rs 08000000 tfd 80 serr 00000000 cmd 0000fb17
(aprobe0:ahcich3:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe0:ahcich3:0:0:0): CAM status: Command timeout
(aprobe0:ahcich3:0:0:0): Error 5, Retries exhausted

Ik blijf mijn Crucial M4 (L2ARC) maar kwijtraken. Ik heb al een firmware-update uitgevoerd en dat heeft toen best wel geholpen. Eerst vloog hij er na een paar dagen al uit, zo erg is het nu niet meer.

Ik dacht eerst dat de firmware-update het probleem helemaal verholpen had, maar ik blijf hem uiteindelijk toch kwijtraken. Hij heeft het nu bijna 3 maanden uitgehouden.

Om hem weer terug te krijgen moet ik de host rebooten, waar ik eigenlijk geen zin in heb.

[Verwijderd]

Kabelproblemen gechecked met SMART (UDMA CRC Error Count)?
Welke controller gebruik je?
Firmware van de SSD geupdate bedoel je? Heb je ook de BIOS firmware en/of firmware van je controller geupdate?