Het grote ZFS topic

[Bananenplant]

Nou, ik ben eens met FreeNAS aan het spelen op een VM en ik vind het allemaal best wel laagdrempelig . Ik heb ook even gekeken hoe het werkt met encryptie: zo te zien kun je de sleutel downloaden, kun je een passphrase zetten en kun je een recovery key downloaden. Na rebooten moet ik unlocken, de recovery key kan ik gebruiken als ik de passphrase ben vergeten. De sleutel downloaden heeft denk ik als functie om 'm te kunnen hergebruiken of om een pool op een ander systeem te kunnen laden...?

Verder snap ik dat key kwijt = data kwijt, dus ik zou 'm dan in elk geval in m'n KeePass-kluis stoppen en nog op een paar veilige plekken bewaren als backup. Maar is er verder nog een reden om niet te encrypten? Ik zag verder dat ik de configuratie kon downloaden als een SQLite-database oid, zit de key daar toevallig ook in?

Verder wel een rare gewaarwording dat ik op de console van de VM zelf door 9 in te drukken als root erin mag zonder een wachtwoord in te geven .

[CurlyMo]

Bananenplant schreef op zondag 7 januari 2018 @ 15:57:
Maar is er verder nog een reden om niet te encrypten?

Dat encryptie nog niet wordt ondersteund door alle OpenZFS varianten en je dus vast zit aan je OS, mocht dat een nadeel voor je zijn. FreeNAS draait op FreeBSD en ondersteund dus geen ZFS encryptie. Linux doet dat wel. Als FreeNAS dus aan full-disk encryption doet, dan kan je je schijven alleen in een FreeBSD machine gebruiken.

[CurlyMo]

Even een dubbelpost gezien de tijd tot mijn laatste.

In december heb ik mijn pilight VPS moeten vervangen aangezien mijn sponsor ermee op hield. Toen naar Vultr gegaan (25GB SSD, 1CPU, 1024MB RAM). Daarop zelf Ubuntu 16.04 geïnstalleerd met ZFS on Root en dat draait eigenlijk sinds helemaal prima. Geen tweaks gedaan aan ZFS zelf, geen dmesg errors.

code:

# uptime
 23:06:31 up 31 days,  2:42,  3 users,  load average: 0.00, 0.02, 0.00

Er zijn zo'n 185 rescursive snapshots.

Alle pilight websites tezamen doen zo'n 50.000 bezoekers per maand op basis van MySQL (forum) en Nginx. Ook draait er één LXD container voor een wordpress site die geen internet toegang heeft buiten poort 80.

Ik zou het tot noch toe dus iedereen aanraden om zijn VPS op ZFS te draaien. Zelfs met weinig geheugen.

[Aschtra]

Looking good:



Even wachten op salaris en dan vervangen.
Kan iemand mij uitleggen hoe dit moet binnen FreeNAS?

Kon zo niet zo snel een kort stappenplan ervoor vinden. Of ik gebruik de verkeerde zoektermen


edit: nvm gevonden

[ Voor 63% gewijzigd door Aschtra op 12-01-2018 16:44 ]

[Paul]

Waar heb je op gezocht? Google: freenas 11 replace disk -> FreeNAS documentation: Replacing a failed drive of FreeNAS documentation: Replacing an encrypted drive

Zonder de "11" werkt ook maar dan krijg je de handleiding van versie 9.3 ipv versie 11; al is de procedure volgens mij grotendeels gelijk gebleven.

[Aschtra]

Paul schreef op vrijdag 12 januari 2018 @ 16:44:
Waar heb je op gezocht? Google: freenas 11 replace disk -> FreeNAS documentation: Replacing a failed drive of FreeNAS documentation: Replacing an encrypted drive

Zonder de "11" werkt ook maar dan krijg je de handleiding van versie 9.3 ipv versie 11; al is de procedure volgens mij grotendeels gelijk gebleven.

Ik heb nu die schijf vervangen (denk ik)
Met zpool status -v zie ik het volgende:



Ik lees dit als het volgende:

De disk die offline is, 11195119714420422158, wordt momenteel vervangen door gptid/938aeaaf-f85a-11e7-b66a-00fd45fd5db4

Resilvering is bezig en momenteel 0.45%

[CurlyMo]

Aschtra schreef op zaterdag 13 januari 2018 @ 13:24:
[...]
Ik lees dit als het volgende:

De disk die offline is, 11195119714420422158, wordt momenteel vervangen door gptid/938aeaaf-f85a-11e7-b66a-00fd45fd5db4

Resilvering is bezig en momenteel 0.45%

Je interpretatie klopt. Aan de output te zien heb je de oude schijf eruit gehaald voordat je de nieuwe ging gebruiken. Zo ja, waarom?

[Aschtra]

CurlyMo schreef op zaterdag 13 januari 2018 @ 13:41:
[...]

Je interpretatie klopt. Aan de output te zien heb je de oude schijf eruit gehaald voordat je de nieuwe ging gebruiken. Zo ja, waarom?

Ik heb het als volgt gedaan:

- In FreeNAS disk als offline markeren
- FreeNAS uitgezet
- Disk eruit
- Nieuwe disk erin
- FreeNAS weer in
- Replace gedaan van de disk in het volume

Waarom ik de oude er eerst uit heb gehaald? Omdat al mijn 4 slots in gebruik zijn. Hoe zou ik dat anders moeten doen?

[ Voor 3% gewijzigd door Aschtra op 13-01-2018 13:53 ]

[CurlyMo]

Aschtra schreef op zaterdag 13 januari 2018 @ 13:52:
[...]
Waarom ik de oude er eerst uit heb gehaald? Omdat al mijn 4 slots in gebruik zijn. Hoe zou ik dat anders moeten doen?

USB? Het blijft het veiligst om de disk online te vervangen.

[Aschtra]

CurlyMo schreef op zaterdag 13 januari 2018 @ 14:01:
[...]

USB? Het blijft het veiligst om de disk online te vervangen.

Heb volgens mij geen case. De documentatie en verschillende filmpjes / guides geven eigenlijk allemaal aan om de schijf offline te zetten.

Zo te zien moet ik straks nog wel de disk die er nu uit is, detachen?

[ Voor 10% gewijzigd door Aschtra op 13-01-2018 14:06 ]

[CurlyMo]

Aschtra schreef op zaterdag 13 januari 2018 @ 14:05:
[...]


Heb volgens mij geen case. De documentatie en verschillende filmpjes / guides geven eigenlijk allemaal aan om de schijf offline te zetten.

Dan is die documentatie niet geheel accuraat. Je kan het besten de schijf live vervangen. Zodra dat is gebeurd, dan zal ZFS automatisch je schijf vrijgeven zodat je hem veilig uit je systeem kan halen.

Zoals jij het nu hebt gedaan komt heel vaak terug in dit topic, maar het is o.a. aan mij om blijvend aan te geven dat dat niet de beste manier is.

Zo te zien moet ik straks nog wel de disk die er nu uit is, detachen?

Ik zou eerst afwachten wat de status wordt zodra hij klaar is met de resilver. Als er dan geen referentie meer is naar je oude schijf, dan kan je hem rustig uit je PC laten.

[Aschtra]

CurlyMo schreef op zaterdag 13 januari 2018 @ 14:12:
[...]

Dan is die documentatie niet geheel accuraat. Je kan het besten de schijf live vervangen. Zodra dat is gebeurd, dan zal ZFS automatisch je schijf vrijgeven zodat je hem veilig uit je systeem kan halen.

Zoals jij het nu hebt gedaan komt heel vaak terug in dit topic, maar het is o.a. aan mij om blijvend aan te geven dat dat niet de beste manier is.


[...]

Ik zou eerst afwachten wat de status wordt zodra hij klaar is met de resilver. Als er dan geen referentie meer is naar je oude schijf, dan kan je hem rustig uit je PC laten.

Doe ik dat de volgende keer Is echter wel de documentatie van FreeNAS zelf als ik het goed zie. De link gebruikt die Paul stuurde.

Uiteraard wacht ik de resilver af om te zien of dat goed is gegaan. Detachen bedoel ik bij de volume binnen FreeNAS. Daarna uit de server fysiek halen.

[CurlyMo]

Aschtra schreef op zaterdag 13 januari 2018 @ 14:16:
[...]
Doe ik dat de volgende keer Is echter wel de documentatie van FreeNAS zelf als ik het goed zie. De link gebruikt die Paul stuurde.

Dan is die documentatie te kort door de bocht. Heb hem zelf overigens niet gelezen.

Detachen bedoel ik bij de volume binnen FreeNAS.

Dat weet ik niet.

[Aschtra]

CurlyMo schreef op zaterdag 13 januari 2018 @ 14:18:
[...]

Dan is die documentatie te kort door de bocht. Heb hem zelf overigens niet gelezen.

[quote[
Detachen bedoel ik bij de volume binnen FreeNAS.
[/quote]
Dat weet ik niet.

Before physically removing the failed device, go to Storage → Volumes. Select the volume’s name. At the bottom of the interface are several icons, one of which is Volume Status. Click the Volume Status icon and locate the failed disk. Then perform these steps:

Step 1: Click the disk’s entry, then its Offline button to change the disk status to OFFLINE. This step is needed to properly remove the device from the ZFS pool and to prevent swap issues. If the hardware supports hot-pluggable disks, click the disk’s Offline button and pull the disk, then skip to step 3. If there is no Offline button but only a Replace button, the disk is already offlined and this step can be skipped.

Als het maar lukt

Bedankt voor de reacties iig!

[Bananenplant]

Ik wil voor het inrichten van mijn datasets even iets controleren. Als ik uiteindelijk snapshots wil gebruiken voor backups met zfs send/receive, is het dan een probleem om meerdere datasets naar het de doel-pool te sturen? Als ik hier kijk lijkt dat niet een probleem te zijn om naast de dataset "dana" nog een andere naar dezelfde pool te sturen, maar ik wilde het even zeker weten, ik kan nu nog relatief gemakkelijk de organisatie van mijn datasets veranderen .

[CurlyMo]

Bananenplant schreef op zaterdag 13 januari 2018 @ 21:34:
Ik wil voor het inrichten van mijn datasets even iets controleren. Als ik uiteindelijk snapshots wil gebruiken voor backups met zfs send/receive, is het dan een probleem om meerdere datasets naar het de doel-pool te sturen?

Nee, mijn backup schijf krijgt vanuit verschillende bronnen zfs streams. Mijn VPS, familieleden, mezelf.

[Bananenplant]

CurlyMo schreef op zaterdag 13 januari 2018 @ 21:37:
[...]

Nee, mijn backup schijf krijgt vanuit verschillende bronnen zfs streams. Mijn VPS, familieleden, mezelf.

Dan hoef ik dus niet voor een overkoepelende dataset te zorgen voor alle datasets die ik wil versturen. Dank .

[nero355]

CurlyMo schreef op donderdag 28 december 2017 @ 10:28:
Ubuntu met ZFS. Verschil met de Raspberry Pi is power over compatibility. Mali GPU's zijn ruk, maar die heb je voor dit doeleind toch niet nodig. De 64-bit SoC en 2GB RAM zijn wel krachtig genoeg voor ZFS

Ik heb laatst wat over die dingen zitten zoeken, vanwege de lage prijs van het kleinste compacte model (dus niet de Orange Pi PC2 maar de Orange Pi Zero) en kwam eigenlijk tot de conclusie dat ze niet geweldig goed ondersteund worden en erg heet worden t.o.v. de Raspberry Pi terwijl ze zo goed als IDLE draaien!

Wat is jouw ervaring ermee tot nu toe ?

[CurlyMo]

nero355 schreef op zaterdag 13 januari 2018 @ 23:55:
[...]

Ik heb laatst wat over die dingen zitten zoeken, vanwege de lage prijs van het kleinste compacte model (dus niet de Orange Pi PC2 maar de Orange Pi Zero) en kwam eigenlijk tot de conclusie dat ze niet geweldig goed ondersteund worden en erg heet worden t.o.v. de Raspberry Pi terwijl ze zo goed als IDLE draaien!

Wat is jouw ervaring ermee tot nu toe ?

Ik heb die specifieke modellen (nog) niet, dus kan er niks over vertellen. Als de temperaturen maar binnen de specs blijven. Desnoods gooi je er een kleine heatsink op.

[Extera]

Guru's!

Mijn FreeNAS systeem geeft de volgende meldingen...

CRITICAL: Jan. 17, 2018, 7:26 p.m. - Device: /dev/da6 [SAT], 176 Currently unreadable (pending) sectors
CRITICAL: Jan. 17, 2018, 7:26 p.m. - Device: /dev/da6 [SAT], 176 Offline uncorrectable

Normaal gesproken zou ik de drive het liefst vervangen....
nu is het echter zo dat ik een drive als spare disk in het systeem heb zitten.

Status van de pool is ook in orde

code:

  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0 in 54h58m with 0 errors on Tue Jan  2 06:58:08 2018
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/1037cdd6-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/3fb9a79f-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/3f209f6e-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/4166bfdc-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/41ff4144-ebb0-11e2-9bc2-00505690dd7d  ONLINE       0     0     0
            gptid/12568da2-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/114c6974-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/151dab3b-5568-11e4-b8aa-0060dd47d1cb  ONLINE       0     0     0
            gptid/0f6dc72a-8095-11e5-b3dc-0060dd47d1cb  ONLINE       0     0     0
            gptid/393af75a-818d-11e5-b3dc-0060dd47d1cb  ONLINE       0     0     0
        spares
          gptid/dff80893-0ddc-11e7-a730-000c29d1beff    AVAIL

Wat is nu de beste actie? Handmatig vervangen? Of wachten tot FreeNAS / ZFS het zelf wel mooi vind geweest, en de spare disk gaat inzetten?

[FireDrunk]

Slaap je er slechter door?

[Extera]

Niet echt

Als het goed is doet ZFS de sectoren toch zelf 'verplaatsen'?
Er is voldoende parity

[FireDrunk]

Lekker laten zitten.

[Extera]

Die melding is irritant

En ja, ik raak er toch onzeker van, inlezen over ZFS is ff geleden

Die smart is volgens mij bar slecht..... duurt niet lang meer en hij gaat echt dood denk ik. ik wacht het wel af

code:

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   089   006    Pre-fail  Always       -       129950432
  3 Spin_Up_Time            0x0003   092   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       51
  5 Reallocated_Sector_Ct   0x0033   095   095   010    Pre-fail  Always       -       3184
  7 Seek_Error_Rate         0x000f   081   057   030    Pre-fail  Always       -       13349747706
  9 Power_On_Hours          0x0032   055   055   000    Old_age   Always       -       39656
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       47
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   096   096   000    Old_age   Always       -       4
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0
189 High_Fly_Writes         0x003a   001   001   000    Old_age   Always       -       497
190 Airflow_Temperature_Cel 0x0022   072   056   045    Old_age   Always       -       28 (Min/Max 19/28)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       47
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       199028
194 Temperature_Celsius     0x0022   028   044   000    Old_age   Always       -       28 (0 19 0 0 0)
197 Current_Pending_Sector  0x0012   099   099   000    Old_age   Always       -       176
198 Offline_Uncorrectable   0x0010   099   099   000    Old_age   Offline      -       176
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       35354h+54m+03.690s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       99741270731
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       437497330229

[ Voor 92% gewijzigd door Extera op 17-01-2018 19:44 ]

[nero355]

Zeker een Seagate HDD ?!

Doe eens gauw vervangen!

[CurlyMo]

Ik zou hem ook vervangen.

---

Na overigens nu al een tijdje de OdroidC2 te hebben draaien als backup target, wordt het een tijd voor een update. Het werk prima Enige wat ik tot nu toe heb moeten tunen is de vmalloc grootte (vmalloc=512M) om dit probleem te verhelpen Dat zou nog een dooddoener kunnen zijn voor de OrangePi PC+, want 512M op de 1GB is wel redelijk wat. De OdroidC2 is 2GB, dus levert meer buffers op.

---

OrangePi PC 2 staat in de bestelling.

[ Voor 94% gewijzigd door CurlyMo op 17-01-2018 20:25 ]

[DarkFire1985]

Nadat gisteren mijn Linux Mint install opeens niets meer deed (mijn databases waren nog wel te benaderen maar verder niets meer, geen video, geen ping, etc.) besloot ik om de server eens te herstarten.
Na het herstarten kreeg ik alleen een zwart scherm met een blinkende cursor, ook wel een black screen of death.

Na wat herstelpogingen besloten om over te stappen naar Proxmox, of allicht een poging daartoe gedaan, maar na het importeren van mijn ZFS on Linux pool zie ik mijn pool wel echter zie ik geen files.

code:

root@homer:/# zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
tank                    16.8T  4.20T   991K  /tank
tank/Backup              376G  4.20T  3.18M  /tank/Backup
tank/Download           2.88G  4.20T  2.88G  /tank/Download
tank/Storage            15.9T  4.20T   687K  /tank/Storage
tank/WWW                2.03G  4.20T   783K  /tank/WWW
tank/XBMC                759M  4.20T   240K  /tank/XBMC
tank/docker             6.65M  4.20T  6.59M  /tank/docker
tank/sync               62.7G  4.20T   192K  /tank/sync
tank/sync/x1            45.3G  4.20T   272K  /tank/sync/x1
tank/sync/local         17.5G  4.20T   208K  /tank/sync/local
tank/sync/x2             192K  4.20T   192K  /tank/sync/x2

code:

root@homer:/# zfs get mountpoint,mounted tank -t filesystem -r
NAME                    PROPERTY    VALUE                    SOURCE
tank                    mountpoint  /tank                    local
tank                    mounted     yes                      -
tank/Backup             mountpoint  /tank/Backup             inherited from tank
tank/Backup             mounted     yes                      -
tank/Download           mountpoint  /tank/Download           inherited from tank
tank/Download           mounted     yes                      -
tank/Storage            mountpoint  /tank/Storage            inherited from tank
tank/Storage            mounted     yes                      -
tank/WWW                mountpoint  /tank/WWW                inherited from tank
tank/WWW                mounted     yes                      -
tank/XBMC               mountpoint  /tank/XBMC               inherited from tank
tank/XBMC               mounted     yes                      -
tank/docker             mountpoint  /tank/docker             inherited from tank
tank/docker             mounted     yes                      -
tank/sync               mountpoint  /tank/sync               inherited from tank
tank/sync               mounted     yes                      -
tank/sync/x1            mountpoint  /tank/sync/x1  inherited from tank
tank/sync/x1            mounted     yes                      -
tank/sync/local         mountpoint  /tank/sync/local         inherited from tank
tank/sync/local         mounted     yes                      -
tank/sync/x2            mountpoint  /tank/sync/x2         inherited from tank
tank/sync/x2            mounted     yes                      -

code:

root@homer:/# ls -al /tank/Storage
total 17
drwxrwxrwx 2 999 1001 2 Jan 20 14:15 .
drwxrwxrwx 9 999 1001 9 Jan 21 00:07 ..

Wat mis ik hier? Hoe krijg ik mijn data weer zichtbaar?

Edit: via snapshots kan ik nog wel bij mijn data...
Mijn data heb ik met ZFS rollback herstelt maar waarom was het überhaupt niet zichtbaar?

[RobertMe]

Toen ik vanmorgen toevallig de status van mijn pools opvroeg kreeg ik een fout terug, alleen weet ik nu niet of er daadwerkelijk iets fout is of dat het om een hickup gaat.

De huidige status output is als volgt (note: scrub heb ik zelf gestart nadat ik de error zag):

code:

  pool: storage
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub in progress since Sun Jan 21 11:03:47 2018
        1.51T scanned out of 3.79T at 118M/s, 5h38m to go
        0B repaired, 39.94% done
config:

        NAME                                        STATE     READ WRITE CKSUM
        storage                                     DEGRADED     0     0     0
          ata-WDC_WD60EFRX-68L0BN1_WD-WX11DA5343J1  DEGRADED     0     0     0  too many errors

errors: No known data errors

Op basis van de vermelde pagina maak ik op dat het normaliter om problemen met replica's zou gaan, maar zoals de output laat ziet heb ik die niet voor deze pool. Daarnaast zou er bij de READ/WRITE/CKSUM een error count moeten staan, en ook die ontbreekt dus. Echter is er dan wel de "too many errors" toevoeging, die weer niet vermeld staat op die pagina.

Moet ik mij in dit geval dus zorgen maken? Of kan ik het simpel oplossen met een zpool clear?

[A1AD]

RobertMe schreef op zondag 21 januari 2018 @ 14:52:
Toen ik vanmorgen toevallig de status van mijn pools opvroeg kreeg ik een fout terug, alleen weet ik nu niet of er daadwerkelijk iets fout is of dat het om een hickup gaat.

De huidige status output is als volgt (note: scrub heb ik zelf gestart nadat ik de error zag):

code:

  pool: storage
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub in progress since Sun Jan 21 11:03:47 2018
        1.51T scanned out of 3.79T at 118M/s, 5h38m to go
        0B repaired, 39.94% done
config:

        NAME                                        STATE     READ WRITE CKSUM
        storage                                     DEGRADED     0     0     0
          ata-WDC_WD60EFRX-68L0BN1_WD-WX11DA5343J1  DEGRADED     0     0     0  too many errors

errors: No known data errors

Op basis van de vermelde pagina maak ik op dat het normaliter om problemen met replica's zou gaan, maar zoals de output laat ziet heb ik die niet voor deze pool. Daarnaast zou er bij de READ/WRITE/CKSUM een error count moeten staan, en ook die ontbreekt dus. Echter is er dan wel de "too many errors" toevoeging, die weer niet vermeld staat op die pagina.

Moet ik mij in dit geval dus zorgen maken? Of kan ik het simpel oplossen met een zpool clear?

Heb je al eens een smart test gedaan?

[CurlyMo]

@RobertMe Het kan ook zo zijn dat de fout een false positive was. Dan verdwijnt het weer vanzelf na je scrub.

[RobertMe]

A1AD schreef op zondag 21 januari 2018 @ 16:10:
[...]


Heb je al eens een smart test gedaan?

Daar had ik nog geen tijd voor gehad. Op basis van @CurlyMo zijn reactie wacht ik even de scrub af en kijk dan morgen verder. SMART zal ik dan waarschijnlijk nog wel steeds even achteraan gaan maar uiteraard met lagere prio. Ik vermoed in ieder geval dat het een false-positive is. Want alweer een tijd terug heb ik een brakke Seagate schijf gehad en die gaf toen wel meteen lees errors etc en dan ook concrete vermeldingen van corrupte bestanden.

Wat ik dan wel weer raar vindt is dat de scrub nu nog steeds 2 uur moet, terwijl die 5,5 uur van vanmiddag al om zijn. En zoveel doet mijn NAS/thuisserver niet dus de lees/scrub snelheid zou vrij constant kunnen zijn.

[RobertMe]

RobertMe schreef op zondag 21 januari 2018 @ 21:27:
[...]

Daar had ik nog geen tijd voor gehad. Op basis van @CurlyMo zijn reactie wacht ik even de scrub af en kijk dan morgen verder. SMART zal ik dan waarschijnlijk nog wel steeds even achteraan gaan maar uiteraard met lagere prio. Ik vermoed in ieder geval dat het een false-positive is. Want alweer een tijd terug heb ik een brakke Seagate schijf gehad en die gaf toen wel meteen lees errors etc en dan ook concrete vermeldingen van corrupte bestanden.

Wat ik dan wel weer raar vindt is dat de scrub nu nog steeds 2 uur moet, terwijl die 5,5 uur van vanmiddag al om zijn. En zoveel doet mijn NAS/thuisserver niet dus de lees/scrub snelheid zou vrij constant kunnen zijn.

Uiteindelijk bleek de scrub pas rond een uur of 2 vannacht afgerond te zijn Maar biede geen soelaas, de pool was nog steeds degraded. S.M.A.R.T. data snel bekeken maar leek niks aan de hand te zijn. Dus maar gegaan voor een zpool clear storage. Echter lijkt dit een nieuwe scrub gestart te hebben, kan dit kloppen? An zich natuurlijk geen ramp, maar nu dus wel een beetje dubbel omdat ik deze zelf ook al had gedaan.

[CurlyMo]

RobertMe schreef op maandag 22 januari 2018 @ 19:37:
[...]

Echter lijkt dit een nieuwe scrub gestart te hebben, kan dit kloppen? An zich natuurlijk geen ramp, maar nu dus wel een beetje dubbel omdat ik deze zelf ook al had gedaan.

Op zich nog wel zoals verwacht. Zoek dit topic maar eens door over mijn defecte RAM. Daarbij kreeg ik ook veel aan fouten bij een scrub. Na het vervangen van de module, waren de fouten na twee scrubs voorbij.

[RobertMe]

CurlyMo schreef op maandag 22 januari 2018 @ 20:01:
[...]

Op zich nog wel zoals verwacht. Zoek dit topic maar eens door over mijn defecte RAM. Daarbij kreeg ik ook veel aan fouten bij een scrub. Na het vervangen van de module, waren de fouten na twee scrubs voorbij.

In dit geval lijkt er dus niks aan de hand te zijn. Nu met de scrub dus maar even afwachten wat er gebeurd en anders maar kijken om een dezer dagen een memtest te doen. Maar ik zal er ook niet blij van worden als idd het RAM kapot is gezien de huidige prijzen . Toevallig paar weken terug nog wat spul gekocht. En waar ik in september '16 nog ~€40 betaalde voor 8GB kost precies hetzelfde RAM nu €80. Liever dus dat ik dat nu niet hoef te vervangen.

[nero355]

RobertMe schreef op maandag 22 januari 2018 @ 19:37:
S.M.A.R.T. data snel bekeken maar leek niks aan de hand te zijn.

Niet om lullig te doen, maar hoe heb je dat gedaan en op basis van wat heb je geconcludeerd dat de S.M.A.R.T. waardes OK zijn ?

Veel mensen die wel vaker ermee de mist in gaan dus vertel eens wat je gecheckt hebt

[RobertMe]

nero355 schreef op maandag 22 januari 2018 @ 22:34:
[...]

Niet om lullig te doen, maar hoe heb je dat gedaan en op basis van wat heb je geconcludeerd dat de S.M.A.R.T. waardes OK zijn ?

Veel mensen die wel vaker ermee de mist in gaan dus vertel eens wat je gecheckt hebt

Voor de volledigheid:

code:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   212   207   021    Pre-fail  Always       -       8366
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       10
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   084   084   000    Old_age   Always       -       11707
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       10
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       0
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always       -       10028
194 Temperature_Celsius     0x0022   128   112   000    Old_age   Always       -       24
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

Dus op het eind "No errors logged", en daarnaast gekeken naar de individuele attributen waar op de logische waardes na de "raw values" 0 zijn en ook de "value" by far niet in de buurt van de buurt van de thresshold komt (alleen power on hours is relatief laag, maar dat staat uiteraard alleen maar voor "oud"/"veel gebruikt" en geeft geen echte fout aan).

[nero355]

RobertMe schreef op dinsdag 23 januari 2018 @ 18:09:
Voor de volledigheid:

code:

  3 Spin_Up_Time            0x0027   212   207   021    Pre-fail  Always       -       8366
  9 Power_On_Hours          0x0032   084   084   000    Old_age   Always       -       11707
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always       -       10028

Dus op het eind "No errors logged", en daarnaast gekeken naar de individuele attributen waar op de logische waardes na de "raw values" 0 zijn en ook de "value" by far niet in de buurt van de buurt van de thresshold komt (alleen power on hours is relatief laag, maar dat staat uiteraard alleen maar voor "oud"/"veel gebruikt" en geeft geen echte fout aan).

Hoe oud is die schijf ?

De Spin_Up_Time waarde vind ik best wel hoog namelijk.
Ik geloof dat die ergens onder de 400 en 600 moet zijn bij een gezonde HDD, maar ik heb ook weleens rare waardes gezien bij gezonde HDD's dus twijfel daar een beetje over

[RobertMe]

nero355 schreef op dinsdag 23 januari 2018 @ 18:49:
[...]

Hoe oud is die schijf ?

De Spin_Up_Time waarde vind ik best wel hoog namelijk.
Ik geloof dat die ergens onder de 400 en 600 moet zijn bij een gezonde HDD, maar ik heb ook weleens rare waardes gezien bij gezonde HDD's dus twijfel daar een beetje over

Schijf is van ik meen september 2016 (in ieder geval ergens die periode). En heeft zo goed als 24/7 gedraaid.

Wat me in ieder geval opvalt is dat de scrub die gisteren was gestart door de clear ook weer lang had gelopen (gisteravond gestart en pas na 10 uur vanmorgen afgerond, dus meer als 12 uur, voor een 6TB schrijf met ong. 4,5TB aan data). Daarnaast was deze nog steeds degrated met "too many errors". Nu dus voor de zekerheid even een update gedaan van Linux (had ook update van de LTS kernel + daarbij behorende ZFS updates/recompilations) een reboot en nog eens een clear gedaan die wederom een scrub starte. Ik ben dus benieuwd wat dit op gaat leveren

Anders morgen ook maar eens een snelheids testje op de HDD doen (hdparm -t dus) om te kijken of dat een beetje in orde is.

[CurlyMo]

RobertMe schreef op dinsdag 23 januari 2018 @ 19:01:
[...]
even een update gedaan van Linux (had ook update van de LTS kernel + daarbij behorende ZFS updates/recompilations)

Als je je OS wilt uitsluiten, pak dan FreeBSD.

[RobertMe]

RobertMe schreef op dinsdag 23 januari 2018 @ 19:01:
Ik ben dus benieuwd wat dit op gaat leveren

Deze nieuwe clean + scrub is nu eindelijk afgelopen:

code:

[robert@nas ~]$ sudo zpool status storage
  pool: storage
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 14h52m with 0 errors on Wed Jan 24 09:50:49 2018
config:

        NAME                                        STATE     READ WRITE CKSUM
        storage                                     ONLINE       0     0     0
          ata-WDC_WD60EFRX-68L0BN1_WD-WX11DA5343J1  ONLINE       0     0     0

errors: No known data errors

En alles lijkt dus in orde te zijn. Scrub snelheid leek rond de 76MB/s te liggen, dus met ong. 3,8TB aan data zou een duur van om en nabij de 14 uur dan ook moeten kloppen. En snelheid van 76MB/s is volgensmij niet zo slecht bij een (single disk) scrub?

[CurlyMo]

RobertMe schreef op woensdag 24 januari 2018 @ 10:20:
[...]
En alles lijkt dus in orde te zijn. Scrub snelheid leek rond de 76MB/s te liggen, dus met ong. 3,8TB aan data zou een duur van om en nabij de 14 uur dan ook moeten kloppen. En snelheid van 76MB/s is volgensmij niet zo slecht bij een (single disk) scrub?

Als er de komende tijd geen nieuwe fouten opduiken, dan lijkt het inderdaad een false positive te zijn geweest.

[nero355]

RobertMe schreef op woensdag 24 januari 2018 @ 10:20:
En alles lijkt dus in orde te zijn.

Mooi!

Scrub snelheid leek rond de 76MB/s te liggen, dus met ong. 3,8TB aan data zou een duur van om en nabij de 14 uur dan ook moeten kloppen. En snelheid van 76MB/s is volgensmij niet zo slecht bij een (single disk) scrub?

Ligt eraan wat voor bestanden je erop hebt : Veel grote bestanden gaat sneller dan veel kleine bestanden en ik geloof dat jouw HDD ongeveer het dubbele kan verwerken dus ik gok dat het een beetje 50/50 is in jouw geval

[RobertMe]

Ik heb vandaag mijn NAS/thuisserver omgebouwd naar een nieuwe behuizing (Silverstone CS380). Deze heeft 8 externe hot swap bays, echter heeft het moederbord maar 6 SATA aansluitingen en uiteraard wil ik wel alle bays kunnen gebruiken mocht dat later nodig blijken te zijn. Daarom heb ik even in de pricewatch zitten zoeken naar een HDD controller en zodoende kwam ik (vrij snel ) uit op deze: pricewatch: Delock PCI Express Card > Hybrid 4 x internal SATA 6 Gb/s RAID - ... En nu ben ik benieuwd of een van jullie ervaring heeft met of deze kaart, of de chip die erop zit (Marvell 88SE9230) of dat ik wellicht beter ver uit de buurt kan blijven hiervan.

Het OS wat ik draai is Linux en daarvan staat in ieder geval aangegeven dat dit ondersteund is.

[FireDrunk]

Volgens mij werkt het wel, en zal je array het prima doen.

Of de snelheid hetzelfde is, durf ik niet te zeggen.

[CurlyMo]

Die dingen zijn op ebay een fractie van de prijs. Ik zou eens in het esxi topic kijken voor inspiratie (bijv. mijn posts).

[RobertMe]

CurlyMo schreef op vrijdag 2 februari 2018 @ 14:59:
Die dingen zijn op ebay een fractie van de prijs. Ik zou eens in het esxi topic kijken voor inspiratie (bijv. mijn posts).

Ik neem aan dat je dan dit kaartje bedoelt?

• Ebay UK
• Ebay DE
• AliExpress

Qua prijs inderdaad vele malen interessanter.

FireDrunk schreef op vrijdag 2 februari 2018 @ 13:33:
Of de snelheid hetzelfde is, durf ik niet te zeggen.

Als ik het na wat uitpluizen goed zag adverteert dat kaartje met snelheden die niet mogelijk zijn. PCIe x4 waar de controller maar x2 is, en wat ik zo snel op Wikipedia wist te herleiden kun je met x2 500MB/s tot 1GB/s behalen waar alleen 1 SATA 3 poort maximaal 600MB/s is.

Alhoewel ik mij tegelijk afvraag hoe relevant dat is? Met gewone HDDs haal je voor zover mijn beperkte kennis gaat niet eens de 200MBs dus met 4 stuks haal je dan ook maximaal maar 800MB/s (500MB/s van PCIe zou dan inderdaad te weinig zijn, maar 1GB/s niet, alhoewel het dan ook weer de vraag is hoe snel ik alle 4 de aansluitingen/disks tegelijk zal gebruiken)

[CurlyMo]

Precies, gewoon een as1061 van ebay.

[nero355]

RobertMe schreef op vrijdag 2 februari 2018 @ 13:18:
Ik heb vandaag mijn NAS/thuisserver omgebouwd naar een nieuwe behuizing (Silverstone CS380). Deze heeft 8 externe hot swap bays, echter heeft het moederbord maar 6 SATA aansluitingen en uiteraard wil ik wel alle bays kunnen gebruiken mocht dat later nodig blijken te zijn.

LSI controller via eBay FTW :
https://www.ebay.com/itm/...troller-Card/122432373851

Kabels had ik een keer via Amazon USA voor peanuts gekocht, maar ik weet niet of dat nog kan :
https://www.amazon.com/gp/product/B001L9DU88/

ASMedia vertrouw ik niet, want ASUS gerelateerd

[CurlyMo]

nero355 schreef op vrijdag 2 februari 2018 @ 22:05:
[...]
ASMedia vertrouw ik niet, want ASUS gerelateerd

Het is echt bij genoeg tweakers hier in gebruik waaronder door mij en werkt echt prima.

[Paul]

Goed, ik heb bij de vorige keer replacen van een disk waarschijnlijk iets fout gedaan; of er is iets anders mis. Nu zijn er op een andere disk unreadable (pending) sectors en wil ik weer een disk vervangen, en daarvoor wil ik graag wat input voordat ik mijn data verkloot

Ik heb een RAID-Z van 5 schijven, en ik heb momenteel in totaal 7 schijven, waarvan 6 aangesloten. Het betreft FreeNAS, dus ik ben niet degene die verzonnen heeft alles met "ada" aan te duiden

ada0 - 37RHKVLTFSAA - 1e "vervangen" schijf
ada1 - Z300RB15 - Originele schijf
ada2 - Z3016XD9 - Originele schijf - 72 unreadable (pending) sectors
ada3 - W300Q1DF - Originele schijf
ada4 - ZFN0EEJ5 - Schijf die ik er net in doe om ada2 mee te vervangen
ada5 - W300NSPP - Originele schijf
xxxx - Z3016ZTB - Defecte schijf, eerder "vervangen" door wat nu ada0 heet, zit niet aangesloten, heb ik nog wel.

Als ik nu een volume aan wil maken (om te kijken welke schijven FreeNAS denkt vrij beschikbaar te hebben) dan komen daar ada1 en ada4 tevoorschijn. Ik vind het vooral erg raar dat ada1 daar tussen staat?

Open ik "Volume Status" in FreeNAS dan geeft deze aan dat "tank" degraded is, dat ada0, ada2, ada3 en ada5 online zijn en dat "182674121090973610" (?) UNAVAIL is. Als ik die laatste wil replacen dan kan ik kiezen uit ada1 en ada4, dezelfde als in de vorige alinea. Oeps. Dan is dus die Toshiba (37RHK..) wel in gebruik genomen maar is er dus een andere schijf uit gegooid?

Als ik dan probeer die rare (1826...) middels "replace" te vervangen door ada1 dan krijg ik de melding dat er al bestanden / partities op staan? Ga ik in /dev kijken dan zie ik inderdaad twee partities en een ada1p1.eli-"bestand" (ik gebruik encryptie binnen FreeNAS).

Wat is nu de veiligste manier om weer bij een gezonde pool te komen? De rare (1826..., unavailable) geforceerd vervangen door ada1 (oudere schijf maar geen lid meer[?] van de pool), en zodra dat klaar is met resilveren ada2 (unreadable pending sectors) vervangen door ada4 (nieuwe, blanco schijf)?

Er staat maar een halve TB op het geheel wat ik echt belangrijk vind (en dat staat ook in Crashplan online) dus dat valt nog wel een keer extra te backuppen maar als ik de boel heel kan houden door het op een doordachte volgorde te doen, dan graag

[CurlyMo]

Kan je eens een commandline zpool status plaatsen. Dat is toch makkelijker voor ons.

[Paul]

Bij deze. Er worden daar echter namen gebruikt die ik zo nog niet gemapt krijg naar zaken die in de GUI staan (zoals ada-nummers of serials)

[root@freenas] ~# zpool status
  pool: freenas-boot
 state: ONLINE
  scan: scrub repaired 0 in 0h0m with 0 errors on Tue Jan 16 03:45:37 2018
config:

        NAME        STATE     READ WRITE CKSUM
        freenas-boot  ONLINE       0     0     0
          da0p2     ONLINE       0     0     0

errors: No known data errors

  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
        the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://illumos.org/msg/ZFS-8000-2Q
  scan: scrub repaired 0 in 11h44m with 0 errors on Sun Jan 28 11:45:00 2018
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                DEGRADED     0     0     0
          raidz1-0                                          DEGRADED     0     0     0
            182674121090973610                              UNAVAIL      0     0     0  was /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a.eli
            gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli  ONLINE       0     0     0
            gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0

errors: No known data errors

[CurlyMo]

Wat is de output als je nu via de command line de zfs replace aftrapt?

[Paul]

Dat is dus mijn vraag: Welke schijf waarmee vervangen? En ik doe het liever via de GUI want die regelt meteen de encrytpie en het gebruik van gptid's.

Ik kan wel

zpool replace tank 182674121090973610 ada1

intypen, maar dan is het niet encrypted en na de volgende reboot is de volgorde weer anders (al kan dat ook komen omdat ik de laatst paar reboots schijven geplaatst (wat nu ada4 heet) en verwijderd (SATA-kabel van een andere disk per ongeluk losgeraakt) heb).

[CurlyMo]

Als je je schijf encrypt, dan is er als het goed is een '.eli' schijf bijgekomen in je /dev map. Je moet de dan pakken in je replace.

[Paul]

En dat encrypten is dus onderdeel van de replace-procedure in de GUI.

ada1 is wel ooit encrypted maar eruit gegooid, ik weet niet 100% zeker dat ik de encryption key nooit heb aangepast dus ik ben huiverig om die zomaar weer toe te voegen in geval de key van die schijf anders is dan de rest, ada4 is niet encrypted.

En ik heb eerlijk gezegd niet zoveel zin het proces wat FreeNAS doorloopt te gaan reverse engineeren om het via de CLI te doen als de GUI hetzelfde ook kan. Ik kan in de GUI (bijvoorbeeld) 182674121090973610 wel replacen met ada1 (daar is het "force" knopje voor) maar ik wil wel graag een tweede (en evt derde ) paar ogen dat dit geen hele domme fout is

[CurlyMo]

Paul schreef op dinsdag 6 februari 2018 @ 09:36:
ada1 is wel ooit encrypted maar eruit gegooid, ik weet niet 100% zeker dat ik de encryption key nooit heb aangepast dus ik ben huiverig om die zomaar weer toe te voegen in geval de key van die schijf anders is dan de rest, ada4 is niet encrypted.

Dit is toch de kern van encryptie. Dat niemand erbij kan behalve jij

En ik heb eerlijk gezegd niet zoveel zin het proces wat FreeNAS doorloopt te gaan reverse engineeren om het via de CLI te doen als de GUI hetzelfde ook kan.

GELI is vrij simpel toe te passen, mits je de sleutel hebt die je wil gebruiken:
http://www.daveeddy.com/2...ion-with-geli-on-freebsd/

Zover ik lees op het FreeNAS forum kan je die sleutel in de GUI downloaden. Als je eenmaal je schijf hebt encrypt, dan heb je een overeenkomstige nieuwe schijf /dev/ada4.eli, die je vervolgens kan gebruiken in je replace functie.

Reverse engineering is klote in geval van rocket science, maar dit is een vrij recht toe recht aan procedure.

Ik kan je alleen zekerheden gegeven met de CLI output.

[Paul]

CurlyMo schreef op dinsdag 6 februari 2018 @ 17:51:
Dit is toch de kern van encryptie. Dat niemand erbij kan behalve jij

Ja, maar dan is het wel handig dat ik er daadwerkelijk bij kan

Als ik Keepass mag geloven is de passphrase sinds januari 2014 (lees: initiële inrichting) niet veranderd, de recovery key is halverwege vorig jaar wel aangepast, waarschijnlijk omdat FreeNAS dat aangeeft bij het replacen van een encrypted disk.

Maar als ik het goed lees raad je dus aan om de "UNAVAIL" schijf die ZFS denkt te moeten hebben (maar niet kan vinden) te replacen met de schone, lege, nieuwe disk? Of was da ada4 in je post een voorbeeld?

[CurlyMo]

Maak eens een simpele opsomming van de kapotte schijven en de nieuwe schijven die je wil gaan gebruiken voor het vervangen ervan?

[Paul]

ada0 - 37RHKVLTFSAA - in vdev, werkt
ada3 - W300Q1DF - in vdev, werkt
ada5 - W300NSPP - in vdev, werkt

182674121090973610 - deel van vdev, geen idee welke schijf dat zou moeten zijn

ada2 - Z3016XD9 - in vdev, 72 unreadable (pending) sectors

ada1 - Z300RB15 - Uit array / vdev gekickt?

ada4 - ZFN0EEJ5 - Gloednieuw

xxxx - Z3016ZTB - defecte schijf, zit niet aangesloten, heb ik nog wel. iirc ook pending sectors, geen tikken

[ Voor 10% gewijzigd door Paul op 06-02-2018 21:24 ]

[CurlyMo]

Doe eens dit:

code:

glabel status

Zodat we weten welke disk nu bij welk id hoort.

[Paul]

Hmm, het kennen van dat soort commando's is toch wel handig

[root@freenas] ~# zpool status
[..]
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                DEGRADED     0     0     0
          raidz1-0                                          DEGRADED     0     0     0
            182674121090973610                              UNAVAIL      0     0     0  was /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a.eli
            gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli  ONLINE       0     0     0
            gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0

errors: No known data errors
[root@freenas] ~# glabel status
                                      Name  Status  Components
gptid/f815465d-03e6-11e6-970a-005056b02901     N/A  da0p1
gptid/7d4b0337-35d1-11e7-8fdd-005056b02901     N/A  ada0p2
gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a     N/A  ada1p2
gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a     N/A  ada2p2
gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a     N/A  ada3p2
gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a     N/A  ada5p2
[root@freenas] ~# 

Met andere woorden, de "UNAVAIL" disk is de ada1 die eruit is gekickt... Die disk is wel aanwezig naar FreeNAS ziet hem niet. In /dev/gptid bestaat wel het ID, maar niet het ID.eli-"bestand", in /dev is er voor ada1 net zoals voor ada0 en ada2 wel een .eli-bestand.

[root@freenas] /dev/gptid# ls -la 7d4b**
crw-r-----  1 root  operator  0x7b Feb  5 22:56 7d4b0337-35d1-11e7-8fdd-005056b02901
crw-r-----  1 root  operator  0xaa Feb  5 22:58 7d4b0337-35d1-11e7-8fdd-005056b02901.eli
[root@freenas] /dev/gptid# ls -la 9407*
crw-r-----  1 root  operator  0x7d Feb  5 22:56 9407a67e-7ecd-11e3-9f1d-002590dbd60a
[root@freenas] /dev# ls -la ada[01]*
crw-r-----  1 root  operator  0x62 Feb  5 22:56 ada0
crw-r-----  1 root  operator  0x68 Feb  5 22:56 ada0p1
crw-r-----  1 root  operator  0x7c Feb  5 22:57 ada0p1.eli
crw-r-----  1 root  operator  0x6a Feb  5 22:56 ada0p2
crw-r-----  1 root  operator  0x64 Feb  5 22:56 ada1
crw-r-----  1 root  operator  0x6c Feb  5 22:56 ada1p1
crw-r-----  1 root  operator  0x8a Feb  5 22:57 ada1p1.eli
crw-r-----  1 root  operator  0x6e Feb  5 22:56 ada1p2

[CurlyMo]

Het eli bestand bestaat dus alleen niet voor het gpt label van ada1, wel voor de ruwe schijf ada1. Heb je al eens geprobeerd om simpelweg een zpool export en zpool import te doen? Of een reboot? Eventueel een reboot met het uitzetten van gpt labels?
https://lists.freebsd.org...ble/2011-June/063000.html

[Paul]

De NAS was al een keer gereboot, maar sindsdien had ik de encryptiesleutel natuurlijk al weer ingegeven. Nu gereboot en de sleutel nog niet ingegeven, en nu heeft /dev/gptid helemaal geen .eli-"bestanden" (ok, snap ik), maar /dev heeft voor alle (niet-nieuwe) schijven wél een .eli-entry, behalve voor ada1...

Als ik de pool unlock dan zegt /var/log/messages maar dat er 4 devices worden gemaakt

Feb  7 10:18:41 freenas GEOM_ELI: Device gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli created.
Feb  7 10:18:41 freenas GEOM_ELI: Encryption: AES-XTS 128
Feb  7 10:18:41 freenas GEOM_ELI:     Crypto: hardware
Feb  7 10:18:42 freenas GEOM_ELI: Device gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli created.
Feb  7 10:18:42 freenas GEOM_ELI: Encryption: AES-XTS 128
Feb  7 10:18:42 freenas GEOM_ELI:     Crypto: hardware
Feb  7 10:18:44 freenas GEOM_ELI: Device gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli created.
Feb  7 10:18:44 freenas GEOM_ELI: Encryption: AES-XTS 128
Feb  7 10:18:44 freenas GEOM_ELI:     Crypto: hardware
Feb  7 10:18:46 freenas GEOM_ELI: Device gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli created.
Feb  7 10:18:46 freenas GEOM_ELI: Encryption: AES-XTS 128
Feb  7 10:18:46 freenas GEOM_ELI:     Crypto: hardware
Feb  7 10:18:47 freenas ZFS: vdev state changed, pool_guid=8392908625464255768 vdev_guid=6673538272358566964
Feb  7 10:18:47 freenas ZFS: vdev state changed, pool_guid=8392908625464255768 vdev_guid=5990669279355631945
Feb  7 10:18:47 freenas ZFS: vdev state changed, pool_guid=8392908625464255768 vdev_guid=11607418960391804261
Feb  7 10:18:47 freenas ZFS: vdev state changed, pool_guid=8392908625464255768 vdev_guid=932183326311054144

En ook in dmesg zijn het er maar 4:

GEOM_ELI: Device ada3p1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device ada2p1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device ada5p1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device ada0p1.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
ctlfe_onoffline: isp0 current WWNN 0x50060b0000655663
ctlfe_onoffline: isp0 current WWPN 0x50060b0000655662
ctlfe_onoffline: SIM isp0 (path id 3) target enable succeeded
ctlfeasync: WWPN 0x50060b0000655666 port 0x0000e8 path 3 target 0 arrived
GEOM_ELI: Device gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware
GEOM_ELI: Device gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: hardware

Ook /var/log/debug.log doet ook maar 4x geli attach:

Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: zpool status freenas-boot
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada0
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada1
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada2
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada3
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada4
Feb  7 10:18:23 freenas manage.py: [middleware.notifier:230] Popen()ing: /usr/sbin/diskinfo ada5
Feb  7 10:18:25 freenas manage.py: [middleware.notifier:230] Popen()ing: /sbin/zfs get -r -H -o name,property,value,source -t filesystem,volume compression,compressratio,readonly,org.freenas:description
Feb  7 10:18:39 freenas manage.py: [middleware.notifier:230] Popen()ing: geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a
Feb  7 10:18:41 freenas manage.py: [middleware.notifier:239] geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a -> 0
Feb  7 10:18:41 freenas manage.py: [middleware.notifier:230] Popen()ing: geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a
Feb  7 10:18:42 freenas manage.py: [middleware.notifier:239] geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a -> 0
Feb  7 10:18:42 freenas manage.py: [middleware.notifier:230] Popen()ing: geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a
Feb  7 10:18:44 freenas manage.py: [middleware.notifier:239] geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a -> 0
Feb  7 10:18:44 freenas manage.py: [middleware.notifier:230] Popen()ing: geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/7d4b0337-35d1-11e7-8fdd-005056b02901
Feb  7 10:18:46 freenas manage.py: [middleware.notifier:239] geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key gptid/7d4b0337-35d1-11e7-8fdd-005056b02901 -> 0
Feb  7 10:18:46 freenas manage.py: [middleware.notifier:230] Popen()ing: zpool import -f -R /mnt 8392908625464255768

Zelfs als ik die schijf zo ver krijg dat deze weer meedoet (geli attach handmatig proberen en dan hopen dat FreeNAS het in het vervolg weer zelf doet?), dan loopt hij natuurlijk dik achter. Heeft het dan nog zin deze toe te voegen of kan ik die net zo goed replacen?

[CurlyMo]

Paul schreef op woensdag 7 februari 2018 @ 10:36:
Zelfs als ik die schijf zo ver krijg dat deze weer meedoet (geli attach handmatig proberen en dan hopen dat FreeNAS het in het vervolg weer zelf doet?), dan loopt hij natuurlijk dik achter. Heeft het dan nog zin deze toe te voegen of kan ik die net zo goed replacen?

Als hij niet kapot is gewoon weer toevoegen. Probleem blijft inderdaad dat hij niet juist attached wordt door FreeNAS.

[Paul]

[root@freenas] /var/log# echo (passphrase) > /tmp/tmpWBWBPb
[root@freenas] /var/log# geli attach -j /tmp/tmpWBWBPb -k /data/geli/ccdab2ed-48f5-42de-8cf0-3571f2349894.key /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a
[root@freenas] /var/log# tail /var/log/messages
Feb  7 10:57:00 freenas GEOM_ELI: Device gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a.eli created.
Feb  7 10:57:00 freenas GEOM_ELI: Encryption: AES-XTS 128
Feb  7 10:57:00 freenas GEOM_ELI:     Crypto: hardware
[root@freenas] /var/log# zpool status
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                DEGRADED     0     0     0
          raidz1-0                                          DEGRADED     0     0     0
            182674121090973610                              UNAVAIL      0     0     0  was /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a.eli
            gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli  ONLINE       0     0     0
            gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0

errors: No known data errors
[root@freenas] /var/log# zpool export tank
cannot unmount '/var/db/system/syslog-60496eb88d7449ae99d5b1af597d46b5': Device busy
[root@freenas] /var/log# zpool import tank
cannot import 'tank': a pool with that name is already created/imported,
and no additional pools with that name were found
[root@freenas] /var/log# zpool online tank /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a
cannot online /dev/gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a: no such device in pool
[root@freenas] /var/log# zpool online tank 182674121090973610
[root@freenas] /var/log# zpool status
  pool: tank
 state: ONLINE
  scan: scrub repaired 0 in 11h44m with 0 errors on Sun Jan 28 11:45:00 2018
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                ONLINE       0     0     0
          raidz1-0                                          ONLINE       0     0     0
            gptid/9407a67e-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/9945a567-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/9e704886-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0
            gptid/7d4b0337-35d1-11e7-8fdd-005056b02901.eli  ONLINE       0     0     0
            gptid/a8c8552e-7ecd-11e3-9f1d-002590dbd60a.eli  ONLINE       0     0     0

errors: No known data errors
[root@freenas] /var/log#

So far, so good. Nu hopen dat het na een reboot zo blijft

Volgende vraag was of ik nog iets moest doen om te zorgen dat de schijf up to date wordt gebracht, maar nu ik wat later nog een `zpool status` aftrap staat er:

  scan: resilvered 53.0M in 0h0m with 0 errors on Wed Feb  7 11:00:20 2018

Geen idee hoe lang die schijf vermist was (ik krijg wel ieder dag mail dat er een update is, en dat de FC verbinding klappert, maar dat de pool degraded is of dat een schijf errors geeft niet... Die krijg ik alleen bij een reboot), maar ~200 MB aan changes lijkt te impliceren dat het niet heel lang geduurd heeft...

[CurlyMo]

Klopt, ziet er goed uit. Ben ook benieuwd naar je reboot. Goed om te lezen welke commando's je zelf hebt geprobeerd om er te komen

[Paul]

één reboot (en een upgrade vandaar de reboot) later en ben weer terug bij af.

In ieder geval weet ik nu dus hoe ik de boel weer online krijg, ik denk dat ik de schijf die bij een reboot verdwijnt door de GUI laat replacen door de nieuwe, zodat alles weer netjes geregistreerd staat en zo, en dat ik daarna de verdwijnende schijf wipe en die gebruik om de schijf met pending sectors te replacen.

[CurlyMo]

Paul schreef op woensdag 7 februari 2018 @ 12:07:
In ieder geval weet ik nu dus hoe ik de boel weer online krijg, ik denk dat ik de schijf die bij een reboot verdwijnt door de GUI laat replacen door de nieuwe, zodat alles weer netjes geregistreerd staat en zo, en dat ik daarna de verdwijnende schijf wipe en die gebruik om de schijf met pending sectors te replacen.

Precies mijn idee bij deze uitkomst. Maak niet dezelfde fout als anderen in dit topic door de schijf die je wilt replacen er eerst uit te gooien.

[hansdegit]

Tevreden gebruiker van ZFSGuru hier, inmiddels wél aan het kijken naar iets dat nog wel onderhouden wordt.

Ik heb 5 mx500's besteld ter vervanging van mijn WD Red's (2x 3TB) en m500 (2x 256GB). Ik wil de nieuwe SSD's in RAID-Z gaan gebruiken.

De huidige 4 devices bezetten de helft van de beschikbare connectoren op mijn moederbord. Ik kan dus niet zondermeer een extra pool creeren van de 5 nieuwe SSD's; ik moet connectoren vrij maken.

Ik heb inmiddels al alle data van de SSD's verplaatst naar de harddisks en ik wil dus de SSD's loskoppelen. Maar: er zit nog een slog op:

code:

  pool: hdtier
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on software that does not support feature
        flags.
  scan: scrub repaired 0 in 6h24m with 0 errors on Mon Jan 15 14:24:11 2018
config:

        NAME             STATE     READ WRITE CKSUM
        hdtier           ONLINE       0     0     0
          mirror-0       ONLINE       0     0     0
            gpt/hdtiera  ONLINE       0     0     0
            gpt/hdtierb  ONLINE       0     0     0
        logs
          gpt/sloga      ONLINE       0     0     0
          gpt/slogb      ONLINE       0     0     0

errors: No known data errors

Ik krijg met een zpool remove die slogs niet verwijderd. Offline zetten lukt prima, maar dan raakt mijn pool degraded.

Wat doe ik fout?
edit: ik heb reeds een bestemming voor de originele Red's en de originele SSD's; het is de bedoeling om die devices sowieso uit mijn systeem te halen.

[ Voor 7% gewijzigd door hansdegit op 07-02-2018 22:39 ]

[CurlyMo]

Zet volgende keer de foutmeldingen ook in je post.

Verder zul je bij een mirrored slog eerst de mirror naar een single device slog moeten zetten via detach. Daarna kan je remove gebruiken.

[hansdegit]

Da's de grap: ik krijg geen foutmeldingen bij de remove.

code:

[root@zfsguru ~]# zpool detach hdtier gpt/slogb
cannot detach gpt/slogb: only applicable to mirror and replacing vdevs
[root@zfsguru ~]#

Zou het kunnen dat ik in mijn onkunde van een aantal jaren geleden een setje van twee slogs heb toegevoegd die niet gemirrord zijn?

[CurlyMo]

hansdegit schreef op woensdag 7 februari 2018 @ 23:07:
Da's de grap: ik krijg geen foutmeldingen bij de remove.

code:

[root@zfsguru ~]# zpool detach hdtier gpt/slogb
cannot detach gpt/slogb: only applicable to mirror and replacing vdevs
[root@zfsguru ~]#

Zou het kunnen dat ik in mijn onkunde van een aantal jaren geleden een setje van twee slogs heb toegevoegd die niet gemirrord zijn?

Inderdaad. Je hebt een RAID0 slog draaien. Toch zou je die ook moeten kunnen verwijderen. Welke pool versie draai je? En is het de bedoeling om deze pool in tact te houden of te vervangen door een nieuwe pool? In dat tweede geval zou je de schijven ook kunnen verwijderen. Dan wordt je pool wel degraded, maar zal die prima functioneren totdat die vervangen is.

[hansdegit]

Mijn pools zijn v28.

UIteindelijk hoef ik geen enkele pool te bewaren. Zodra ik de data van pool "hdtier" naar de nieuw te bouwen RAIDZ pool heb overgezet, kan pool "hdtier" gewoon weg. Sterker: ik ga de schijven in een Synology zetten.

Even dubbelcheck: de SSD's waarop de slogs staan kan ik gewoon uit de machine trekken waarna de pool iig leesbaar blijft?

Da's wel even een testje waard.
1) machine netjes afsluiten
2) SSD's verwijderen
3) machine opbrengen
4) check of "hdtier" nog lekker functioneert.

Thx CurlyMo.

(nabrander: zou het handig zijn om mijn pools te upgraden naar v5000 of verder?)

[CurlyMo]

Die stappen zijn inderdaad wat het is. v5000 is handig als je een bepaalde feature flag nodig hebt.

[savale]

Even mijn ervaring hier delen. Ik heb een ryzen 1700 / asrock b350 pro / 32gb ram / 512gb nvme / 5x 8tb westerndigital reds. Geen gekke dingen gezien bij de SMART status.

Op dit systeem draait proxmox vme 5.1 met daarop freenas geïnstalleerd (16gb / 8 cores). De schijven heb ik direct aan het guest os met freenas toegekend. Ik ben begonnen met een degraded raidz2 array. De data gekopieerd en vervolgens de 2 schijven erbij gehangen.
Helaas na het resilver process toch wat problemen. Hij geeft aan dat er een aantal files beschadigt zijn. De array was nog steeds degraded en alle 3 de schijven die voorheen ONLINE stonden staan nu op DEGRADED. De 2 later toegevoegde schijven staan wel netjes op ONLINE.
Na een reboot start hij direct weer met resilvering van de 2 nieuwe schijven.
Ik zit nu te denken aan een zpool clear of een scrub.

Nog wel iets opmerkelijks: de eerste 3 schijven lijken niet gepartioneerd. De 2 later toegevoegde schijven zijn wel door freenas gepetitioneerd.

[FireDrunk]

Hoe heb je de schijven doorgegeven aan de VM? En is het een Container of een 'echte' VM?

_{Overigens is het gepartitioneerd, heel wat anders dan gepetitioneerd , staat je Chrome autocorrect aan?}

[ Voor 41% gewijzigd door FireDrunk op 08-02-2018 18:31 ]

[savale]

FireDrunk schreef op donderdag 8 februari 2018 @ 18:30:
Hoe heb je de schijven doorgegeven aan de VM? En is het een Container of een 'echte' VM?

_{Overigens is het gepartitioneerd, heel wat anders dan gepetitioneerd , staat je Chrome autocorrect aan?}

Haha heerlijk die autocorrect. Het is een echte VM (geen container). Ik heb ze als volgt doorgegeven:

qm set 101 -virtio1 /dev/disk/by-id/ata-WDC_WD80EZZX-11xxxx
qm set 101 -virtio2 /dev/disk/by-id/ata-WDC_WD80EZZX-11yyyy

etc.

[FireDrunk]

Hmm, dat is een soort RDM. Zitten die schijven gewoon op een onboard controller of een losse controller?
Ik heb iets meer vertrouwen in PCIe Passthrough. Op zich is de Device Passthrough van KVM (via Virtio) wel aardig, maar ik heb er weinig ervaring mee.

[savale]

FireDrunk schreef op donderdag 8 februari 2018 @ 19:00:
Hmm, dat is een soort RDM. Zitten die schijven gewoon op een onboard controller of een losse controller?
Ik heb iets meer vertrouwen in PCIe Passthrough. Op zich is de Device Passthrough van KVM (via Virtio) wel aardig, maar ik heb er weinig ervaring mee.

ze zitten op de onboard controller. Tja twijfel of het misschien niet slimmer is om de Passthrough te doen van de hele sata controller. (SMART werkt nu bijvoorbeeld ook niet in de guest)

Zou het resilveren trouwens zelf het probleem moeten oplossen of moet ik een zpool clear doen om van die degraded state af te komen?

[FireDrunk]

Durf ik niet met zekerheid te zeggen. Als er corruptie optreed door het kanaal wat gebruikt wordt, weet je nooit zeker hoe ver dat gaat.

[savale]

FireDrunk schreef op donderdag 8 februari 2018 @ 19:06:
Durf ik niet met zekerheid te zeggen. Als er corruptie optreed door het kanaal wat gebruikt wordt, weet je nooit zeker hoe ver dat gaat.

Hmmz toch maar opnieuw beginnen misschien en de backup terug zetten....

[CurlyMo]

savale schreef op donderdag 8 februari 2018 @ 19:10:
[...]


Hmmz toch maar opnieuw beginnen misschien en de backup terug zetten....

Als je toch een backup hebt zou ik eerst kijken wat er gebeurt na een passthrough.

[Paul]

CurlyMo schreef op woensdag 7 februari 2018 @ 12:08:
Maak niet dezelfde fout als anderen in dit topic door de schijf die je wilt replacen er eerst uit te gooien.

Ik volg het topic al langer dan vandaag

Anyway, ada1 (schijf die na een reboot niet meer bij de pool kwam) is gereplaced met de nieuwe schijf. De schijf met pending sectors replacen met ada1 ging niet zonder slag of stoot via de GUI (kreeg de restjes niet weggepoetst, niet met replace -f en niet met wipe), maar wat Google-opdrachten,

sysctl kern.geom.debugflags=0x10
dd if=/dev/zero of=/dev/ada1 bs=512 count=1

en een reboot later (het is BSD, had vast ook anders gekunnen ) is de pool dan toch aan het replacen

[savale]

CurlyMo schreef op donderdag 8 februari 2018 @ 19:13:
[...]

Als je toch een backup hebt zou ik eerst kijken wat er gebeurt na een passthrough.

Nog wat gelezen in het proxmox forum en het blijkt dat het tegenwoordig beter is om virtio-scsi te gebruiken in plaats van virtio.
S.M.A.R.T. werkt nu ook ineens in freenas. Ik ben alleen bang dat ik mijn pool niet helemaal 100% in orde ga krijgen, dus ik ga het nog maar een keer helemaal opnieuw proberen. Inmiddels voldoende schijven / ruimte vrij om niet degraded te hoeven beginnen...

[FireDrunk]

Virtio is een fractie sneller dan virtio-scsi. Grootste verschil is support voor UNMAP & DISCARD (TRIM).
Als je dus op een SAN / iSCSI LUN zit, is Virtio leuker, zit je lokaal op SSD's te krassen is virtio-scsi leuker.

[savale]

FireDrunk schreef op vrijdag 9 februari 2018 @ 12:20:
Virtio is een fractie sneller dan virtio-scsi. Grootste verschil is support voor UNMAP & DISCARD (TRIM).
Als je dus op een SAN / iSCSI LUN zit, is Virtio leuker, zit je lokaal op SSD's te krassen is virtio-scsi leuker.

bedankt voor deze info! Voor 5400k 8tb sata600 schijven zal het waarschijnlijk niet veel uit gaan maken.

[FireDrunk]

Daar maakt het inderdaad geen fluit uit

[FireDrunk]

Woei, een _hele_ oude bug in ZFS on Linux is eindelijk opgelost!

https://github.com/zfsonlinux/zfs/issues/3801

[FutureCow]

FireDrunk schreef op maandag 12 februari 2018 @ 10:22:
Woei, een _hele_ oude bug in ZFS on Linux is eindelijk opgelost!

https://github.com/zfsonlinux/zfs/issues/3801

Als ik het zo lees is de bug niet opgelost, maar verdwijnt de bug als 0.8 ooit uit gaat komen waarbij ZFS en SPL gecombineerd zijn. Daar is nog lang geen sprake van...

Of begrijp ik het verkeerd?

[FireDrunk]

De bug is dus wel opgelost, maar nog niet gereleased

[kaaas]

Voor de experts.
Ik heb het volgende probleem.
Ik heb een pool waar na scrubben checksum fouten te voor schijn komen.
Nu zou je denken dat er dan iets mis is met de disk waar de checksum fouten bij staat.
Maar Smart geeft geen enkel probleem op die specifieke disk en trouwens ook niet op de andere disks in de pool.
Nog vreemder is dat als ik in dmesg kijk er IO errors zijn op een andere disk dan op die waar zfs van vind van dat er wat mis is.
Rara wie heeft enig idee wat er mis is.
Het kan toch niet zo zijn dat er checksum errors ontstaan door fouten op de andere disk. Dat lijkt me een zeer slechte implementatie van checksums.

Ik heb de disks al van slot veranderd dan veranderd er niets.

Systeem heeft ecc geheugen
ubunty 16.04
libzfs2linux 0.6.5.6-0ubuntu15

code:

   pool: disk1
  state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
     attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
     using 'zpool clear' or replace the device with 'zpool replace'.
    see: http://zfsonlinux.org/msg/ZFS-8000-9P
   scan: scrub repaired 13.1M in 8h25m with 0 errors on Thu Feb 15 23:35:38 2018
config:

     NAME        STATE     READ WRITE CKSUM
     disk1       ONLINE       0     0     0
       raidz1-0  ONLINE       0     0     0
         B30     ONLINE       0     0     0
         B31     ONLINE       0     0     0
         B32     ONLINE       0     0     0
         B33     ONLINE       0     0     0
         B35     ONLINE       0     0     0
         B34     ONLINE       0     0    76

dmesg let op sdr is dus niet B34 het is B35

code:

[2433926.105164] blk_update_request: I/O error, dev sdr, sector 7662068256
[2433926.111797] sd 14:0:7:0: [sdr] tag#4 Sense Key : Aborted Command [current] 
[2433926.111804] sd 14:0:7:0: [sdr] tag#4 Add. Sense: Information unit iuCRC error detected
[2433926.111808] sd 14:0:7:0: [sdr] tag#4 CDB: Read(16) 88 00 00 00 00 01 c8 b1 e1 e8 00 00 00 38 00 00
[2433926.111812] blk_update_request: I/O error, dev sdr, sector 7662068200

smart

code:

=== START OF INFORMATION SECTION ===
Device Model:     ST10000VN0004-1ZD101
Serial Number:    
LU WWN Device Id: 
Firmware Version: SC60
User Capacity:    10,000,831,348,736 bytes [10.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Feb 16 15:54:52 2018 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (  567) seconds.
Offline data collection
capabilities:            (0x7b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   1) minutes.
Extended self-test routine
recommended polling time:    ( 858) minutes.
Conveyance self-test routine
recommended polling time:    (   2) minutes.
SCT capabilities:          (0x50bd) SCT Status supported.
                    SCT Error Recovery Control supported.
                    SCT Feature Control supported.
                    SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   075   064   044    Pre-fail  Always       -       35195496
  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       4
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   077   060   045    Pre-fail  Always       -       51862819
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       853 (124 52 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       4
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   092   092   000    Old_age   Always       -       8
190 Airflow_Temperature_Cel 0x0022   064   062   040    Old_age   Always       -       36 (Min/Max 30/36)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       299
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       1
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       1815
194 Temperature_Celsius     0x0022   036   040   000    Old_age   Always       -       36 (0 22 0 0 0)
195 Hardware_ECC_Recovered  0x001a   006   004   000    Old_age   Always       -       35195496
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       153
200 Multi_Zone_Error_Rate   0x0023   100   100   001    Pre-fail  Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       195 (183 17 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       10170672443
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       26801348269

[FREAKJAM]

FireDrunk schreef op maandag 12 februari 2018 @ 10:22:
Woei, een _hele_ oude bug in ZFS on Linux is eindelijk opgelost!

https://github.com/zfsonlinux/zfs/issues/3801

Wow, dat heeft wel even geduurd. Draai daarom ook al geruime tijd de kmod variant vanwege deze bug. In het verleden vaak last gehad van deze bug op mijn CentOS 7 bak.

[nero355]

@kaaas Vervang eens de kabel van de HDD waarvan je de errors en S.M.A.R.T. data hebt gepost : Als het goed is zal je dan de error niet meer zien, tenzij de controller of poort op het moederbord problemen geeft of eventueel de controller van de HDD zelf

Deze waarde mag dan ook niet meer oplopen :
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 153

[CurlyMo]

@kaaas zorg eerst dat je post leesbaar is. Gebruik code tags bijv. Ik ga het nu niet lezen.

[kaaas]

@nero355 Dat maakt niet uit zoals ik ook gepost had ik had hem al in een ander slot gedaan op de backplane.
, die 199 UDMA_CRC_Error_Count komt van het live er uit hallen van de disk.
Ook loopt 199 niet op tijden gebruik.
En het verklaart nog steeds niet waarom dmesg en zfs verschillende disk rapporteren.

[nero355]

kaaas schreef op vrijdag 16 februari 2018 @ 19:26:
@nero355 Dat maakt niet uit zoals ik ook gepost had ik had hem al in een ander slot gedaan op de backplane.
, die 199 UDMA_CRC_Error_Count komt van het live er uit hallen van de disk.
Ook loopt 199 niet op tijden gebruik.
En het verklaart nog steeds niet waarom dmesg en zfs verschillende disk rapporteren.

Het matched anders wel je errors in het OS

Dit lijkt me ook niet gezond :

code:

195 Hardware_ECC_Recovered  0x001a   006   004   000    Old_age   Always       -       35195496

[CurlyMo]

Ik zou eens de SMART waardes in het SMART topic laten interpreteren.

[kaaas]

De smart waardes zijn van de disk die zfs als problematisch aan merkt. Niet die van de dmesg berichten.
Waarde 195 is is geen getal waar je iets aan kunt ontlenen. Wikipedia: S.M.A.R.T..
Ik zei niet voor niets dat de smart waardes prima zijn.

@CurlyMo Als ik op smart zoek zijn er vele topic is er een grote overkoepelende die je aanraad?

De vraag is waarom zfs en dmesg tegenstrijdige info geven. Hoe werkt een scrub ik ga er van uit dat hij de informatie van de 5 andere disks gebruikt om de 6e te checken. Maar dit lijkt er bij na op dat hij maar 1 disk gebruikt en dat hij de verkeerde als fout aanmerkt. Maar ik kan me dus niet voorstellen dat een raidz zo werkt.

[ Voor 12% gewijzigd door kaaas op 16-02-2018 20:00 ]

[CurlyMo]

kaaas schreef op vrijdag 16 februari 2018 @ 19:56:
De smart waardes zijn van de disk die zfs als problematisch aan merkt. Niet die van de dmesg berichten.
Waarde 195 is is geen getal waar je iets aan kunt ontlenen. Wikipedia: S.M.A.R.T..
Ik zei niet voor niets dat de smart waardes prima zijn.

@CurlyMo Als ik op smart zoek zijn er vele topic is er een grote overkoepelende die je aanraad?

Check je SMART

De vraag is waarom zfs en dmesg tegenstrijdige info geven.

Dat vraag ik me ook af. Ik zou dit toch ook nogmaals drie keer controleren.

Hoe werkt een scrub ik ga er van uit dat hij de informatie van de 5 andere disks gebruikt om de 6e te checken. Maar dit lijkt er bij na op dat hij maar 1 disk gebruikt en dat hij de verkeerde als fout aanmerkt. Maar ik kan me dus niet voorstellen dat een raidz zo werkt.

ZFS ziet een schijf die fouten laat zien die worden gerepareerd. Het aantal geconstateerde fouten zie je op schijf niveau en het aantal gerepareerde globaal.