Het grote ZFS topic

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:01:
Er wordt gelukkig wat geprobeerd.

Uiteraard, anders leer ik niks toch?

Tijd om daadwerkelijk te hulp te schieten

En dit bedoel ik dus met het elitaire.

Plaats eens een

zpool status

  pool: data
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: scrub repaired 176K in 0 days 17:08:56 with 0 errors on Sun Aug 11 17:32:57 2019
config:

        NAME        STATE     READ WRITE CKSUM
        data        DEGRADED     0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
          raidz1-1  DEGRADED     0     0     0
            sdh     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdi     OFFLINE      0     0     0
            sdg     ONLINE       0     0     0

[CurlyMo]

Kijk eens drie keer naar die eerste foutmelding. Kan me bijna niet voorstellen dan je het dan niet ziet.

CH4OS schreef op woensdag 14 augustus 2019 @ 21:03:
[...]
En dit bedoel ik dus met het elitaire.

Een mooie geuzennaam

[CH4OS]

Heb nu eerst

zpool online data

gedaan, toen kwam de melding dat ik met replace alsnog de disk moest vervangen. Dit geprobeerd, maar wederom de melding dat er no such device is. Ik neig dan toch wederom naar de GUID van de defecte disk te moeten zoeken en die als waarde voor old-disk te moeten gebruiken. Klopt die aanname?

Output van zpool status:

  pool: data
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: scrub in progress since Wed Aug 14 21:06:45 2019
        193M scanned at 32.2M/s, 24K issued at 4K/s, 20.5T total
        0B repaired, 0.00% done, no estimated completion time
config:

        NAME        STATE     READ WRITE CKSUM
        data        DEGRADED     0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
          raidz1-1  DEGRADED     0     0     0
            sdh     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdi     UNAVAIL      0     0     0  corrupted data
            sdg     ONLINE       0     0     0

[ Voor 63% gewijzigd door CH4OS op 14-08-2019 21:09 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:08:
Klopt die aanname?

Ik zal het voor je verwoorden:



Als ik het goed begrijp probeer je HDD met ID ata-WDC_WD40EFRX-68N32N0_WD-WCC7K2YS6RCV te vervangen door /dev/sdi.

Nog abstracter:

ata-WDC_WD40EFRX-68N32N0_WD-WCC7K2YS6RCV moet /dev/sdi worden.

Klopt dat?

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:11:
Als ik het goed begrijp probeer je HDD met ID ata-WDC_WD40EFRX-68N32N0_WD-WCC7K2YS6RCV te vervangen door /dev/sdi.

Yes. De oude disk (eindigend met 6RCV) was voorheen dan ook /dev/sdi. Overigens werkt het ook niet als ik het new-device als ID opgeef.

[ Voor 79% gewijzigd door CH4OS op 14-08-2019 21:13 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:12:
[...]
Yes. De oude disk (eindigend met 6RCV) was voorheen dan ook /dev/sdi. Overigens werkt het ook niet als ik het new-device als ID opgeef.

Dus je vervangt eigenlijk /dev/sdi met /dev/sdi?

---

Doe eens een:

sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

[ Voor 12% gewijzigd door CurlyMo op 14-08-2019 21:15 ]

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:14:
[...]

Dus je vervangt eigenlijk /dev/sdi met /dev/sdi?

Ik vervang een reeds verwijderde disk (want geen hotswap of ruimte over) met een andere.

Doe eens een:

sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL

NAME   FSTYPE      SIZE MOUNTPOINT LABEL
sda                 50G
├─sda1 ext4         46G /
├─sda2               1K
└─sda5 swap          4G [SWAP]
sdb                1.8T
├─sdb1 zfs_member  1.8T            data
└─sdb9               8M
sdc                1.8T
├─sdc1 zfs_member  1.8T            data
└─sdc9               8M
sdd                1.8T
├─sdd1 zfs_member  1.8T            data
└─sdd9               8M
sde                1.8T
├─sde1 zfs_member  1.8T            data
└─sde9               8M
sdf                3.7T
├─sdf1 zfs_member  3.7T            data
└─sdf9               8M
sdg                3.7T
├─sdg1 zfs_member  3.7T            data
└─sdg9               8M
sdh                3.7T
├─sdh1 zfs_member  3.7T            data
└─sdh9               8M
sdi                3.7T
├─sdi1             3.7T
└─sdi9               8M
sr0               1024M

Ik heb dus vier 2TB schijven in een raidz1 pool en vier 4TB schijven in een andere raidz1 pool. De 50GB disk is de virtuele disk voor de VM. De disks hangen aan een IBM M1015 controller die ik met passthrough aan de VM doorgeef.

[ Voor 75% gewijzigd door CH4OS op 14-08-2019 21:17 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:15:
[...]
Ik vervang een reeds verwijderde disk (want geen hotswap of ruimte over) met een andere.


[...]

NAME   FSTYPE      SIZE MOUNTPOINT LABEL
sda                 50G
├─sda1 ext4         46G /
├─sda2               1K
└─sda5 swap          4G [SWAP]
sdb                1.8T
├─sdb1 zfs_member  1.8T            data
└─sdb9               8M
sdc                1.8T
├─sdc1 zfs_member  1.8T            data
└─sdc9               8M
sdd                1.8T
├─sdd1 zfs_member  1.8T            data
└─sdd9               8M
sde                1.8T
├─sde1 zfs_member  1.8T            data
└─sde9               8M
sdf                3.7T
├─sdf1 zfs_member  3.7T            data
└─sdf9               8M
sdg                3.7T
├─sdg1 zfs_member  3.7T            data
└─sdg9               8M
sdh                3.7T
├─sdh1 zfs_member  3.7T            data
└─sdh9               8M
sdi                3.7T
├─sdi1             3.7T
└─sdi9               8M
sr0               1024M

Dus je oude schijf werd sdi gelabeled en de nieuwe ook?

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:17:
Dus je oude schijf werd sdi gelabeled en de nieuwe ook?

Correct.

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:17:
[...]
Correct.

Doe dan eens een:

zpool replace data /dev/sdi /dev/sdi

[CH4OS]

Zojuist gedaan. Hij heeft opeens wat tijd nodig, hopelijk is dat een goed teken!

[DataGhost]

Met het risico elitair over te komen, had ik eigenlijk gehoopt dat je

DataGhost schreef op woensdag 14 augustus 2019 @ 20:07:
dan zou je even man zpool in moeten rammelen, en bij het stukje over zpool replace kijken hoe het allemaal werkt.

gedaan had. Daar stond namelijk

quote: man zpool

zpool replace [-f] [-o property=value] pool device [new_device]
Replaces old_device with new_device. This is equivalent to attaching new_device, waiting for it to resilver, and then detaching old_device.

The size of new_device must be greater than or equal to the minimum size of all the devices in a mirror or raidz configuration.

new_device is required if the pool is not redundant. If new_device is not specified, it defaults to old_device. This form of replacement is useful after an existing disk has failed and has been physically replaced. In this case, the new disk may have the same /dev path as the old device, even though it is actually a different disk. ZFS recognizes this.

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:19:
Zojuist gedaan. Hij heeft opeens wat tijd nodig, hopelijk is dat een goed teken!

Nog steeds tijd nodig?

@DataGhost Fijn dat je nu op de "teach a man to fish" tour bent i.p.v. de "give a man a fish"

[ Voor 19% gewijzigd door CurlyMo op 14-08-2019 21:28 ]

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:26:
Nog steeds tijd nodig?

Hij is nog steeds wel bezig inderdaad.

DataGhost schreef op woensdag 14 augustus 2019 @ 21:26:

Gekke is wel dat dat dan weer foutmeldingen geeft bij mij.

EDIT:
Nu is ie klaar.

  pool: data
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Aug 14 21:30:17 2019
        151G scanned at 2.96G/s, 46.9G issued at 942M/s, 20.5T total
        0B resilvered, 0.22% done, 0 days 06:18:58 to go
config:

        NAME             STATE     READ WRITE CKSUM
        data             DEGRADED     0     0     0
          raidz1-0       ONLINE       0     0     0
            sdb          ONLINE       0     0     0
            sdd          ONLINE       0     0     0
            sde          ONLINE       0     0     0
            sdc          ONLINE       0     0     0
          raidz1-1       DEGRADED     0     0     0
            sdh          ONLINE       0     0     0
            sdf          ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              old        UNAVAIL      0     0     0  corrupted data
              sdi        ONLINE       0     0     0
            sdg          ONLINE       0     0     0

errors: No known data errors

Is de output van zpool status. Ik neem aan dat de machine nu dus eea aan het replacen is en dat vanzelf verdwijnt wanneer het voltooid is?

[ Voor 101% gewijzigd door CH4OS op 14-08-2019 21:33 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:27:
[...]
Hij is nog steeds wel bezig inderdaad.
[...]
Gekke is wel dat dat dan weer foutmeldingen geeft bij mij.

Nee, want wat @DataGhost acceert is precies wat je nu gedaan hebt n.a.v. mijn suggestie.

[CH4OS]

CurlyMo schreef op woensdag 14 augustus 2019 @ 21:32:
Nee, want wat @DataGhost acceert is precies wat je nu gedaan hebt n.a.v. mijn suggestie.

Nou ja, in die zin dat ik dus de daadwerkelijk oude disk aangaf en daarna de nieuwe...
Dus vind het ergens nog wel vaag om twee keer dezelfde disk te hebben opgegeven.

EDIT:
Maar nu er dus een kopje 'replacing' is verschenen, is hij nu dus de data aan het herstellen en verdwijnt dat stukje vanzelf als dat gereed is, of moet ik nu nog verdere dingen doen?

[ Voor 21% gewijzigd door CH4OS op 14-08-2019 21:35 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:34:
[...]
Maar nu er dus een kopje 'replacing' is verschenen, is hij nu dus de data aan het herstellen en verdwijnt dat stukje vanzelf als dat gereed is, of moet ik nu nog verdere dingen doen?

Dat antwoord krijg je over 7 uur

[CH4OS]

Thanks voor de hulp in elk geval! #blijmee

En ja, weet dat het niet hoeft, maar wil het deze keer gewoon wel gezegd hebben.

[ Voor 54% gewijzigd door CH4OS op 14-08-2019 21:42 ]

[CurlyMo]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:40:
Thanks voor de hulp in elk geval! #blijmee

Net nog niet

[CH4OS]

Resilvering is intussen gestart, dus voor het gevoel ben ik halverwege, hahaha

[nero355]

CH4OS schreef op woensdag 14 augustus 2019 @ 20:53:
Ik heb met zpool replace geprobeerd, maar wat ik al dacht, werkt dat dus niet direct, want de defecte disk heb ik niet meer in de pool zitten, dus die klapt er uit met een dergelijke foutmelding

Waarom doe je zoiets

Een post of 10-ish voordat jij de eerste post maakte over het probleem heb ik nog dit gepost : nero355 in "Het grote ZFS topic"

Kost het echt zoveel moeite om effe van de pool af te blijven en de Search van dit Topic te gebruiken of gewoon effe een stukje terug te lezen

CH4OS schreef op woensdag 14 augustus 2019 @ 21:15:
Ik vervang een reeds verwijderde disk (want geen hotswap of ruimte over) met een andere.

Wat ik in zulke gevallen altijd deed was de HDD die niet in de kast paste op een doosje naast de kast plaatsen en ervoor zorgen dat iedereen eraf bleef met zijn of haar poten!

[CH4OS]

nero355 schreef op donderdag 15 augustus 2019 @ 00:01:
Waarom doe je zoiets

Omdat ik 8 disks heb en maar 8 disks kwijt kan op de controller?

Kost het echt zoveel moeite om effe van de pool af te blijven en de Search van dit Topic te gebruiken of gewoon effe een stukje terug te lezen

En wie ben jij om dit te vragen als het probleem intussen ook al dik opgelost is? Moet ik jou verantwoording afleggen of zo? Lees dan ook het topic even, want dat heb je duidelijk ook niet gedaan. Iets met een balk, een splinter en ogen.

Wat ik in zulke gevallen altijd deed was de HDD die niet in de kast paste op een doosje naast de kast plaatsen en ervoor zorgen dat iedereen eraf bleef met zijn of haar poten!

Dat had in mijn geval niets uitgemaakt; Ik heb 8 disks en de controller kan ook maar 8 disks aansturen. Succes met zorgen dat de boel niet degraded is dan terwijl je een disk vervangt...

[ Voor 14% gewijzigd door CH4OS op 15-08-2019 00:07 ]

[nero355]

CH4OS schreef op donderdag 15 augustus 2019 @ 00:03:
Omdat ik 8 disks heb en maar 8 disks kwijt kan op de controller?

En wat doet je Onboard SATA AHCI Controller

]En wie ben jij om dit te vragen als het probleem intussen ook al dik opgelost is? Moet ik jou verantwoording afleggen of zo? Lees dan ook het topic even, want dat heb je duidelijk ook niet gedaan.

Ik heb juist alle posts gelezen en werd er juist verdrietig van dat iemand zo met zijn data omgaat...

Dat gaat in mijn geval niets uitmaken. Ik heb 8 disks en de controller kan ook maar 8 disks. Succes met tellen.

Dat is het mooie van ZFS : Je kon ook gewoon een andere Controller erbij pakken en later alleen de disks omruilen!

[CH4OS]

nero355 schreef op donderdag 15 augustus 2019 @ 00:08:
En wat doet je Onboard SATA AHCI Controller

Lees mijn berichten even.

Ik heb juist alle posts gelezen en werd er juist verdrietig van dat iemand zo met zijn data omgaat...

Vreemd, dat je eerst vraagt of er geen plek was op de onboard sata controller, terwijl ik letterlijk in een post zeg dat ik het in een VM draai en de IBM M1015 controller middels passthrough aan de VM doorgeef.

De onboard SATA controller is er dus ten eerste al niet (in die zin dat de VM het niet ziet of er weet van heeft), en ten tweede heb ik daarop de datastores zitten voor ESXi (die poorten zijn dus ook vol), want ook die disks heb ik met SATA aangesloten en heb ik dus niet voor VM's beschikbaar. En volgens mij gaat een ICH10R controller niet zo lekker met passthrough in ESXi, ik weet in elk geval dat RAID icm die controller en ESXi geen succes is.

En als dat (intussen) wel gaat, prima; maar waar is de betreffende VM dan? Want na instellen van passthrough moet je rebooten (bij ESXi in elk geval wel) en dan zijn opeens de datastores weg, omdat het apparaat doorgegeven wordt naar een VM, die er dan niet is...

Dat is het mooie van ZFS : Je kon ook een andere Controller erbij pakken en later alleen de disks omruilen!

Dat weet en snap ik, maar nogmaals, die ruimte heb ik dus niet (zie hierboven waarom). En tot zover de aannames. Als het een optie was, had ik dat namelijk zeker wel gedaan.

[ Voor 26% gewijzigd door CH4OS op 15-08-2019 00:30 ]

[Betaside]

Betaside schreef op maandag 5 augustus 2019 @ 19:22:
[...]
Gisteren nog een scrub gestart en nu blijkt dat hij is door gelopen zonder enig probleem. Ik bouw zometeen mijn picopsu er weer in en kijk of hij zo stabiel blijft. Lijkt er echt op als of het probleem opgelost is...

Een update van mijn kant. Ik heb de afgelopen 9 dagen een paar intensieve schrijf tests en scrubs laten lopen icm mijn pico psu. Daarnet ging het weer mis, een paar write errors en een degraded pool. Na een reboot wou hij de disk niet meer mounten dus heb ik beslist om de andere voeding weer in te bouwen en de disks op een andere poort aan te sluiten. Nu is mijn pool weer online (resilvering loopt nog). Ik denk dat ik toch wat langer bij deze voeding blijf om te kijken of er echt geen error meer optreden.

Groetjes!

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 00:10:
[...]
Dat weet en snap ik, maar nogmaals, die ruimte heb ik dus niet (zie hierboven waarom). En tot zover de aannames. Als het een optie was, had ik dat namelijk zeker wel gedaan.

Een USB naar SATA controller is ook een controller

[CH4OS]

CurlyMo schreef op donderdag 15 augustus 2019 @ 10:57:
Een USB naar SATA controller is ook een controller

Dergelijke controllers heb ik niet. Er speciaal er een voor gaan halen is ook weer zoiets, of versnelt het bijvoorbeeld het vervangen of resilveren/herstellen van de data er enorm mee?

Reden dat ik dit vraag is het volgende. Ik wil volgend jaar, of over 1m5 jaar, moet even kijken, namelijk de 4x 2TB raidz1 vervangen voor wat groters en daarna de raidz1 dan vergroten uiteraard.

Als een USB SATA-controller het vervangen / upgraden enorm versnelt/versimpelt dan kan ik altijd even kijken hier naar.

[ Voor 9% gewijzigd door CH4OS op 15-08-2019 14:16 ]

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 14:12:
[...]
Als een USB SATA-controller het vervangen / upgraden enorm versnelt/versimpelt dan kan ik altijd even kijken hier naar.

Vertraagd alleen maar, maar maakt het wel een stuk veiliger.

[CH4OS]

CH4OS schreef op woensdag 14 augustus 2019 @ 21:27:

  pool: data
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Wed Aug 14 21:30:17 2019
        151G scanned at 2.96G/s, 46.9G issued at 942M/s, 20.5T total
        0B resilvered, 0.22% done, 0 days 06:18:58 to go
config:

        NAME             STATE     READ WRITE CKSUM
        data             DEGRADED     0     0     0
          raidz1-0       ONLINE       0     0     0
            sdb          ONLINE       0     0     0
            sdd          ONLINE       0     0     0
            sde          ONLINE       0     0     0
            sdc          ONLINE       0     0     0
          raidz1-1       DEGRADED     0     0     0
            sdh          ONLINE       0     0     0
            sdf          ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              old        UNAVAIL      0     0     0  corrupted data
              sdi        ONLINE       0     0     0
            sdg          ONLINE       0     0     0

errors: No known data errors

Is de output van zpool status. Ik neem aan dat de machine nu dus eea aan het replacen is en dat vanzelf verdwijnt wanneer het voltooid is?

Nog altijd is de machine bezig met resilveren. Het gekke is dat als ik de status opvraag het soms ook gebeurd dat de procentuele voortgang minder is als letterlijk 10s ervoor en dat begrijp ik eigenlijk niet helemaal. Ook zag ik een keer voorbij komen dat eea gestart of cancelled was op 1 januari 1970 (de unix epoc dus...) Nu heb ik natuurlijk ook wel redelijk veel data, dus het zou ook weer raar zijn als het snel klaar was, maar dan lijkt het mij wel dat je dan enkel de totale progress ziet en niet dat het stapsgewijs gaat, toch?

Van nieuwste naar oudste:

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 15 19:51:07 2019
        64.9G scanned at 64.9G/s, 20.2G issued at 20.2G/s, 20.5T total
        0B resilvered, 0.10% done, 0 days 00:17:20 to go

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 15 19:44:58 2019
        272G scanned at 136G/s, 84.6G issued at 42.3G/s, 20.5T total
        0B resilvered, 0.40% done, 0 days 00:08:14 to go

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 15 19:41:09 2019
        908G scanned at 53.4G/s, 281G issued at 16.5G/s, 20.5T total
        30.0M resilvered, 1.34% done, 0 days 00:20:53 to go

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 15 19:38:10 2019
        472G scanned at 157G/s, 147G issued at 48.9G/s, 20.5T total
        0B resilvered, 0.70% done, 0 days 00:07:07 to go

Met wat zoeken kwam ik een ander topic alhier tegen, daar wordt ook gesuggereerd dat mogelijk de nieuwe disk dan misschien toch niet zo goed is... Ik hoop niet dat dat hier ook het geval is. De SMART-data van de nieuwe disk ziet er volgens mij ook niet vreemd uit;

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   100   253   021    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       2
  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   100   100   000    Old_age   Always       -       23
 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       -       2
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       0
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       7
194 Temperature_Celsius     0x0022   111   110   000    Old_age   Always       -       39
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

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 19:58:
[...]
Van nieuwste naar oudste:

Dit betekent dat je resilver elke keer opnieuw begint wegens een of andere fout in je schijven. Zie je niks geks in de rest van je zpool status?

[CH4OS]

CurlyMo schreef op donderdag 15 augustus 2019 @ 20:00:
[...]

Dit betekent dat je resilver elke keer opnieuw begint wegens een of andere fout in je schijven. Zie je niks geks in de rest van je zpool status?

  pool: data
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Aug 15 20:02:31 2019
        958G scanned at 56.3G/s, 296G issued at 17.4G/s, 20.5T total
        25.8M resilvered, 1.41% done, 0 days 00:19:48 to go
config:

        NAME             STATE     READ WRITE CKSUM
        data             DEGRADED     0     0     0
          raidz1-0       ONLINE       0     0     0
            sdb          ONLINE       0     0     0
            sdd          ONLINE       0     0     0
            sde          ONLINE       0     0     0
            sdc          ONLINE       0     0     0
          raidz1-1       DEGRADED     0     0     0
            sdh          ONLINE       0     0     0
            sdf          ONLINE       0     0     0
            replacing-2  DEGRADED     0     0     0
              old        UNAVAIL      0     0     0  corrupted data
              sdi        ONLINE       0     0     0  (resilvering)
            sdg          ONLINE       0     0     0

errors: No known data errors

Dit is een complete output van zpool status.

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 20:03:
[...]
Dit is een complete output van zpool status.

En je dmesg?

[CH4OS]

CurlyMo schreef op donderdag 15 augustus 2019 @ 20:06:
En je dmesg?

Ik zie wel zaken als

[ 2780.158681] INFO: task zfs:8993 blocked for more than 120 seconds.
[ 2780.158692]       Tainted: P           O      4.18.0-1-amd64 #1 Debian 4.18.6-1
[ 2780.158705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

voorbij komen.

Met deze call trace er achteraan:

[ 2780.158302] zed             D    0  1150      1 0x00000000
[ 2780.158303] Call Trace:
[ 2780.158310]  ? __schedule+0x2b7/0x880
[ 2780.158311]  ? __switch_to_asm+0x40/0x70
[ 2780.158312]  ? __switch_to_asm+0x34/0x70
[ 2780.158314]  schedule+0x28/0x80
[ 2780.158315]  schedule_preempt_disabled+0xa/0x10
[ 2780.158316]  __mutex_lock.isra.3+0x1a0/0x4e0
[ 2780.158364]  ? spa_open_common+0x5f/0x4f0 [zfs]
[ 2780.158387]  spa_open_common+0x5f/0x4f0 [zfs]
[ 2780.158412]  spa_get_stats+0x54/0x520 [zfs]
[ 2780.158415]  ? __alloc_pages_nodemask+0xf8/0x250
[ 2780.158418]  ? kmalloc_large_node+0x37/0x60
[ 2780.158419]  ? __kmalloc_node+0x203/0x2a0
[ 2780.158445]  zfs_ioc_pool_stats+0x34/0x80 [zfs]
[ 2780.158473]  zfsdev_ioctl+0x49d/0x8c0 [zfs]
[ 2780.158475]  ? do_futex+0x4b5/0xad0
[ 2780.158478]  ? __switch_to_asm+0x40/0x70
[ 2780.158479]  ? __switch_to_asm+0x34/0x70
[ 2780.158480]  ? __switch_to_asm+0x40/0x70
[ 2780.158480]  ? __switch_to_asm+0x34/0x70
[ 2780.158481]  ? __switch_to_asm+0x40/0x70
[ 2780.158482]  ? __switch_to_asm+0x40/0x70
[ 2780.158486]  do_vfs_ioctl+0xa4/0x640
[ 2780.158487]  ? __x64_sys_futex+0x13b/0x190
[ 2780.158488]  ksys_ioctl+0x70/0x80
[ 2780.158490]  __x64_sys_ioctl+0x16/0x20
[ 2780.158492]  do_syscall_64+0x55/0x110
[ 2780.158493]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2780.158495] RIP: 0033:0x7f0678fc5427
[ 2780.158495] Code: Bad RIP value.
[ 2780.158499] RSP: 002b:00007f06781626c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 2780.158500] RAX: ffffffffffffffda RBX: 00007f06781626f0 RCX: 00007f0678fc5427
[ 2780.158500] RDX: 00007f06781626f0 RSI: 0000000000005a05 RDI: 0000000000000009
[ 2780.158501] RBP: 00007f0678165cd0 R08: 00007f0670027c40 R09: 00007f0670000090
[ 2780.158501] R10: 00007f06700008d0 R11: 0000000000000246 R12: 00007f0670018760
[ 2780.158502] R13: 0000558d344850e0 R14: 0000000000000000 R15: 00007f0678165cf4

[ Voor 87% gewijzigd door CH4OS op 15-08-2019 20:08 ]

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 20:07:
[...]

Ik zie wel zaken als

[ 2780.158681] INFO: task zfs:8993 blocked for more than 120 seconds.
[ 2780.158692]       Tainted: P           O      4.18.0-1-amd64 #1 Debian 4.18.6-1
[ 2780.158705] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

voorbij komen.

Met deze call trace er achteraan:

[ 2780.158302] zed             D    0  1150      1 0x00000000
[ 2780.158303] Call Trace:
[ 2780.158310]  ? __schedule+0x2b7/0x880
[ 2780.158311]  ? __switch_to_asm+0x40/0x70
[ 2780.158312]  ? __switch_to_asm+0x34/0x70
[ 2780.158314]  schedule+0x28/0x80
[ 2780.158315]  schedule_preempt_disabled+0xa/0x10
[ 2780.158316]  __mutex_lock.isra.3+0x1a0/0x4e0
[ 2780.158364]  ? spa_open_common+0x5f/0x4f0 [zfs]
[ 2780.158387]  spa_open_common+0x5f/0x4f0 [zfs]
[ 2780.158412]  spa_get_stats+0x54/0x520 [zfs]
[ 2780.158415]  ? __alloc_pages_nodemask+0xf8/0x250
[ 2780.158418]  ? kmalloc_large_node+0x37/0x60
[ 2780.158419]  ? __kmalloc_node+0x203/0x2a0
[ 2780.158445]  zfs_ioc_pool_stats+0x34/0x80 [zfs]
[ 2780.158473]  zfsdev_ioctl+0x49d/0x8c0 [zfs]
[ 2780.158475]  ? do_futex+0x4b5/0xad0
[ 2780.158478]  ? __switch_to_asm+0x40/0x70
[ 2780.158479]  ? __switch_to_asm+0x34/0x70
[ 2780.158480]  ? __switch_to_asm+0x40/0x70
[ 2780.158480]  ? __switch_to_asm+0x34/0x70
[ 2780.158481]  ? __switch_to_asm+0x40/0x70
[ 2780.158482]  ? __switch_to_asm+0x40/0x70
[ 2780.158486]  do_vfs_ioctl+0xa4/0x640
[ 2780.158487]  ? __x64_sys_futex+0x13b/0x190
[ 2780.158488]  ksys_ioctl+0x70/0x80
[ 2780.158490]  __x64_sys_ioctl+0x16/0x20
[ 2780.158492]  do_syscall_64+0x55/0x110
[ 2780.158493]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 2780.158495] RIP: 0033:0x7f0678fc5427
[ 2780.158495] Code: Bad RIP value.
[ 2780.158499] RSP: 002b:00007f06781626c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 2780.158500] RAX: ffffffffffffffda RBX: 00007f06781626f0 RCX: 00007f0678fc5427
[ 2780.158500] RDX: 00007f06781626f0 RSI: 0000000000005a05 RDI: 0000000000000009
[ 2780.158501] RBP: 00007f0678165cd0 R08: 00007f0670027c40 R09: 00007f0670000090
[ 2780.158501] R10: 00007f06700008d0 R11: 0000000000000246 R12: 00007f0670018760
[ 2780.158502] R13: 0000558d344850e0 R14: 0000000000000000 R15: 00007f0678165cf4

Je ZFS module lijkt te hangen. Draai je de laatste zfs versie?

[CH4OS]

CurlyMo schreef op donderdag 15 augustus 2019 @ 20:10:
Je ZFS module lijkt te hangen. Draai je de laatste zfs versie?

Volgens mij wel. Ik draai de volgende versie:

root@VM-OLYMPUS:~# dmesg | grep ZFS
[    8.937523] ZFS: Loaded module v0.8.1-4, ZFS pool version 5000, ZFS filesystem version 5

EDIT: Volgens de site in elk geval wel.

[ Voor 5% gewijzigd door CH4OS op 15-08-2019 20:13 ]

[CurlyMo]

CH4OS schreef op donderdag 15 augustus 2019 @ 20:11:
[...]
Volgens mij wel. Ik draai de volgende versie:

root@VM-OLYMPUS:~# dmesg | grep ZFS
[    8.937523] ZFS: Loaded module v0.8.1-4, ZFS pool version 5000, ZFS filesystem version 5

Misschien heeft @FireDrunk een idee?

[FireDrunk]

Niet direct, je zou een ZFS versie terug kunnen gaan. Als ik morgen tijd heb, zal ik even kijken of ik iets vergelijkbaars kan vinden in de issue tracker.

Ziet er uit als een bugje in een low level call (sys ioctl).
Kan driver gerelateerd zijn of kernel interfacing van zfs zelf.

[CurlyMo]

FireDrunk schreef op donderdag 15 augustus 2019 @ 20:21:
Niet direct, je zou een ZFS versie terug kunnen gaan. Als ik morgen tijd heb, zal ik even kijken of ik iets vergelijkbaars kan vinden in de issue tracker.

Ziet er uit als een bugje in een low level call (sys ioctl).
Kan driver gerelateerd zijn of kernel interfacing van zfs zelf.

Het is tegenwoordig een beetje vloeken in de kerk, maar toch FreeBSD maar eens proberen?

[FireDrunk]

Laatste versies zijn niet helemaal compatible meer dacht ik, maar je zou idd even de flag usage kunnen bekijken.

[CH4OS]

@FireDrunk Zou het een verschil kunnen uitmaken als ik een bootable USB stick met FreeBSD maak en daarmee de pool ga resilveren?

EDIT:

FireDrunk schreef op donderdag 15 augustus 2019 @ 20:26:
Laatste versies zijn niet helemaal compatible meer dacht ik, maar je zou idd even de flag usage kunnen bekijken.

Nu ik erover nadenk, ik kan mij wel herinneren dat er een keer een melding voorbij kwam over het upgraden van pools. Maar dat wilde ik juist pas doen na het resilveren om het risico op dataloss te verlagen.

[ Voor 63% gewijzigd door CH4OS op 15-08-2019 21:15 ]

[FireDrunk]

Verstandige keuze. Resilveren kan op alle platformen (mits de pool read-write geimporteerd kan worden), maar bedenk wel even dat de labels van je pool anders kunnen zijn. Boeit niet veel. Zijn voor de sier. Intern hebben die dingen een ID.

[CH4OS]

FireDrunk schreef op donderdag 15 augustus 2019 @ 21:21:
Verstandige keuze. Resilveren kan op alle platformen (mits de pool read-write geimporteerd kan worden), maar bedenk wel even dat de labels van je pool anders kunnen zijn. Boeit niet veel. Zijn voor de sier. Intern hebben die dingen een ID.

Nou ja, ik zat nu dus meer te denken dat de pool upgraden wellicht een optie is als daarna het resilveren wel goed werkt omdat dan de incompatabilities weg zijn?

[ Voor 4% gewijzigd door CH4OS op 15-08-2019 21:25 ]

[FireDrunk]

Nee, zeker niet doen. Upgraden is het wijzigen van feature flags. Heeft weinig met ZFS kernel module versies te maken. Een upgrade hier betekend dat je meer features toestaat op je pool.

Bootable usb stick is prima. Kan ook met een linux live iso. Kan je prima live ZFS op installeren.

[ Voor 21% gewijzigd door FireDrunk op 15-08-2019 21:29 ]

[DataGhost]

Zegt

zpool events

nog iets speciaals?

[zzattack]

Ik probeer te achterhalen waar de bottleneck in mijn setup zit. De pool bestaat uit 2 vdevs, 1 van 10x4TB raidz2 + 1 van 10x8TB in raidz2. Sequential writes zitten boven 2GB/s sustained, maar reads averagen ongeveer 250MB/s. Momenteel geen zil/l2arc SSD (maar zou wel kunnen).

De 2e vdev met 8TB disks is toegevoegd toen de pool op ~80% utilization zat. Er is dus zeker sprake van enige imbalance, maar ook nieuw weggeschreven data kan niet snel sequentieel teruggelezen worden. Vanuit ARC saturate ik 10Gbe moeiteloos over SMB maar wanneer de data echt van de disks moet komen vallen de prestaties erg tegen.

Ik zit op FreeBSD 12 en heb geen tunables aangepast. Zit 128GB ECC RAM in en de gebruikte HBA's zijn SAS2008 based in it mode/mps driver. SMART op alle disks is goed.
Monitoren van zpool iostat/iostat -x tijdens grote read operations onthult geen problemen, alle disks schommelen tussen 10-20MB/s bandwidth. Er wordt niet constant op 1 disk gewacht en er is niet 1 disk die achterblijft bij de rest.
Volgens mij is een probleem met de controller uitgesloten omdat scrubs wel met 800MB/s gaan en daarbij de drukbezette disks uit de kleinere vdev continue met >100MB/s per disk belast.

Iemand suggesties om te achterhalen wat hier nu de bottleneck vormt?

[FireDrunk]

Wat is je recordsize en logbias? En wat is je vdev prefetch?

[zzattack]

Recordsize heb ik van 128k naar 1M veranderd zonder verschil te merken. Prefetch staat uit (kernel default indien RAM >= 4G) en logbias=latency (ook default).

[CH4OS]

Kleine update; afgelopen weekend weinig gebeurd ivm visite en een BBQ (wat heb ik toch een slecht leven he). Momenteel loopt resilvering via een FreeBSD dat ik vanaf een USB stick heb geboot en het lijkt vooralsnog goed te gaan (zit nu op 5%).

Het systeem geeft aan ongeveer nog wat uurtjes bezig te zijn, dus straks maar eens kijken en rond middernacht nog een keer. Het lijkt nu in elk geval progressie te maken. Ook fijn dat de IBM M1015 (die naar de LSI IT mode is geflashed) standaard herkend wordt door FreeBSD en ZFS standaard aanwezig is. Het laat mij ergens wel twijfelen om de data pool over te zetten naar FreeBSD, eigenlijk. Maar eerst de data nu maar herstellen, dat is het belangrijkste voor mij op het moment.

Wilde ook gelijk even gebruik maken van de gelegenheid om weer te bedanken voor de geboden hulp! Ben er erg blij mee!

Edit: na een kleine 11,5 uur was de resilvering klaar!

[ Voor 17% gewijzigd door CH4OS op 21-08-2019 11:46 ]

[Dutch2007]

CH4OS schreef op maandag 19 augustus 2019 @ 19:51:
Kleine update; afgelopen weekend weinig gebeurd ivm visite en een BBQ (wat heb ik toch een slecht leven he). Momenteel loopt resilvering via een FreeBSD dat ik vanaf een USB stick heb geboot en het lijkt vooralsnog goed te gaan (zit nu op 5%).

Het systeem geeft aan ongeveer nog wat uurtjes bezig te zijn, dus straks maar eens kijken en rond middernacht nog een keer. Het lijkt nu in elk geval progressie te maken. Ook fijn dat de IBM M1015 (die naar de LSI IT mode is geflashed) standaard herkend wordt door FreeBSD en ZFS standaard aanwezig is. Het laat mij ergens wel twijfelen om de data pool over te zetten naar FreeBSD, eigenlijk. Maar eerst de data nu maar herstellen, dat is het belangrijkste voor mij op het moment.

Wilde ook gelijk even gebruik maken van de gelegenheid om weer te bedanken voor de geboden hulp! Ben er erg blij mee!

Edit: na een kleine 12,5 uur was de resilvering klaar!

Gaat het nu ook goed in je linux omgeving?

De reden dat het trager werkt in FreeBSD is dat in 0.8.x incremental scrub is toegevoegd, dan gaat het met GB/TB/sec ipv MB/sec

[FireDrunk]

zzattack schreef op zaterdag 17 augustus 2019 @ 13:37:
Recordsize heb ik van 128k naar 1M veranderd zonder verschil te merken. Prefetch staat uit (kernel default indien RAM >= 4G) en logbias=latency (ook default).

Er zijn 2 soorten prefetch. ZFS heeft een globale prefetch, en er is een prefetch op vdev niveau.
Die laatste helpt behoorlijk voor reads is mijn ervaring, met als downside, wat verlies van IOPS.

http://fibrevillage.com/s...-linux-performance-tuning

Zie kopjes: "ZFS File level prefetch tuning" en "ZFS Device level prefetch tuning".

Er zijn ook nog linux kernel opties om readahead op device niveau te verhogen, buiten ZFS kom.
Die kunnen ook behoorlijk helpen:

sudo blockdev --setra 4096 /dev/sda

[CH4OS]

Dutch2007 schreef op woensdag 21 augustus 2019 @ 10:32:
Gaat het nu ook goed in je linux omgeving?

De reden dat het trager werkt in FreeBSD is dat in 0.8.x incremental scrub is toegevoegd, dan gaat het met GB/TB/sec ipv MB/sec

Ja, in Debian gaat het ook gewoon goed.

[zzattack]

Ik draai nog onder FreeBSD en de device level prefetch stond wel aan (sysctl zfs.vfs.prefetch_disable=0).
Onderstaand beeld is een representatieve weergave van m'n gemiddeldes. Ver beneden de maat volgens mij. Ik heb intussen de pool gebalanceerd wat erin heeft geresulteerd dat ik nu constant 20 disks heb die 10MB/s doe i.p.v. 10 disks die 15MB/s doen.

Denk dat dit de sleutel nog niet is..

code:

                      capacity     operations    bandwidth
pool               alloc   free   read  write   read  write
-----------------  -----  -----  -----  -----  -----  -----
store              35.0T  74.0T  1.37K    793   195M  88.5M
  raidz2           5.33T  30.9T    741    128   102M  12.7M
    label/store02      -      -    131     26  12.5M  1.68M
    label/store06      -      -    125     26  12.5M  1.68M
    label/store05      -      -    123     25  12.6M  1.68M
    label/store03      -      -    132     26  12.5M  1.68M
    label/store09      -      -    118     25  12.6M  1.68M
    label/store04      -      -    130     26  12.5M  1.68M
    label/store10      -      -    132     26  12.5M  1.68M
    label/store01      -      -    164     27  12.4M  1.68M
    label/store07      -      -    123     25  12.6M  1.68M
    label/store08      -      -    132     26  12.5M  1.68M
  raidz2           29.7T  43.1T    663    665  92.9M  75.8M
    label/store11      -      -     71     88  11.8M  9.96M
    label/store12      -      -     69     88  11.8M  9.96M
    label/store13      -      -     69     88  11.8M  9.96M
    label/store14      -      -     71     89  11.8M  9.96M
    label/store15      -      -     76    111  11.7M  9.94M
    label/store16      -      -     90    108  11.7M  9.94M
    label/store17      -      -     85    104  11.8M  9.94M
    label/store18      -      -     90    106  11.8M  9.94M
    label/store19      -      -     90    107  11.7M  9.94M
    label/store20      -      -     90    107  11.7M  9.94M

[FireDrunk]

Waarmee test je?

Overigens zie je aan jouw post heel duidelijk dat je systeem 'maar' 64k per IO opvraagt aan je storage. Dat is natuurlijk erg inefficient. Je device readahead hoger zetten, zou erg helpen, en zorgen dat ZFS grotere IO's naar je disks stuurt zal ook behoorlijk helpen.

[ Voor 89% gewijzigd door FireDrunk op 21-08-2019 14:20 ]

[Weiman]

Snappen jullie dit? Ik gebruik Xigmanas (voormalig NAS4Free, afsplitsing van FreeNAS) en heb het mobo/RAM/CPU geupgradet. Ging best goed, beetje aanmodderen met de NIC goed zetten maar het viel me op dat mijn server die via ISCSI de drie ZFS volumes niet meer zag. Ik dus de targets opnieuw configureren en zag dat je de optie hebt om onder één target meerdere LUNs te zetten, eerst had ik een één target per LUN/ZFS Volume. Handig, leek me.

Dit was het resultaat, een 2TB GPT partitie op twee van de volumes erbij. Why? Screenshotje van nadat ik er weer drie targets van gemaakt heb: https://imgur.com/a/5FIPEOZ

Ik met tools als testdisk en EaseUS aan de slag, testdisk ziet de oude partitie inclusief naam en data en ik kan, zegt ie een logical disk partitie terugschrijven, maar vervolgends heb ik nog steeds deze 2TB partitie ertussenin zitten.
Ik kan dus waarscchijnlijk data recovery gaan doen op file-niveau, yay Gelukkig houd ik het 3-2-1 principe aan met data die echt belangrijk is, maar hier stond toch wel wat op waarvan ik het liefst even kijken of het lukt.
Maar goed, weer wat van geleerd, niet alleen een config backup maar ook een ZFS snapshot maken voortaan. Ja, dat had ik helaas hiervoor nog nooit gedaan, my bad.

[CurlyMo]

Weiman schreef op donderdag 22 augustus 2019 @ 01:08:
Maar goed, weer wat van geleerd, niet alleen een config backup maar ook een ZFS snapshot maken voortaan. Ja, dat had ik helaas hiervoor nog nooit gedaan, my bad.

Snappen jullie dit?

Nee

Al doe je het niet periodiek, dan altijd voor een migratie.

[Brahiewahiewa]

Weiman schreef op donderdag 22 augustus 2019 @ 01:08:
...
Dit was het resultaat, een 2TB GPT partitie op twee van de volumes erbij. Why? Screenshotje van nadat ik er weer drie targets van gemaakt heb: https://imgur.com/a/5FIPEOZ
...

Je ziet dat windows het "GPT protective partitions" noemt; dat doet alleen de 32bits versie.
Tijd om je windows te upgraden?

[Weiman]

Brahiewahiewa schreef op donderdag 22 augustus 2019 @ 12:55:
[...]

Je ziet dat windows het "GPT protective partitions" noemt; dat doet alleen de 32bits versie.
Tijd om je windows te upgraden?

Ah, dat het Protective Partition had ik even gemist. Beetje googlen leidt tot:

"The other reason is that partition table on the hard drive is corrupted or damaged. In this case, the disk also shows protective partition even though it is connected to a 64-bit system."

Ik draai gelukkig gewoon een 64-bit OS. Conclusie is dus dat dit soort van standaard gedrag is van windows bij een partitietabel die fubar is. Weer wat geleerd, maar nog steeds apart dat dit de partitietabellen compleet sloopt.

[Brahiewahiewa]

Weiman schreef op vrijdag 23 augustus 2019 @ 08:47:
[...]


Ah, dat het Protective Partition had ik even gemist. Beetje googlen leidt tot:

"The other reason is that partition table on the hard drive is corrupted or damaged. In this case, the disk also shows protective partition even though it is connected to a 64-bit system."

Ik draai gelukkig gewoon een 64-bit OS. Conclusie is dus dat dit soort van standaard gedrag is van windows bij een partitietabel die fubar is. Weer wat geleerd, maar nog steeds apart dat dit de partitietabellen compleet sloopt.

Zie ik het goed dat je ISTGT gebruikt? Da's min of meer depricated. De code van CTL wordt nog wel onderhouden

[Weiman]

Goed punt, ik moet toch de boel opnieuw gaan opbouwen dus dan maar eens kijken of ik het met CTL kan doen in plaats van ISTGT.

[Simkin]

Na een upgrade van mijn Debian OS, plus recompile naar zfs 8.0, zag ik geen enkele file/dir meer staan op mijn geïmporteerde pool. Dit uiteindelijk opgelost door een handmatige export en daarna deze dmv "zpool import -d /dev/disk/by-id POOLNAME" weer te importeren.

Deel het even hier in het geval dat iemand anders hier tegen aan loopt.

[ Voor 16% gewijzigd door Simkin op 19-09-2019 19:01 ]

[cyspoz]

Ik draai Freenas en heb een uitdaging met mijn boot pool. Die bestond eerst uit een enkele USB Daarop zijn een 4 tal bestanden corrupt geraakt. Ik heb toen een extra USB toegevoegd, dat ging goed maar loste natuurlijk niet de data corruptie op. Daarna wilde ik de bestaande corrupte USB vervangen door nog een nieuwe, maar die replace actie is blijven hangen.
Ondertussen heb ik een update gedaan naar 11.2-U6 waarbij ik hoopte dat de corrupte bestanden overschreven zouden worden met nieuwe versies en het probleem opgelost zou zijn.
Dat was niet het geval, ook niet na een nieuwe scrub. Ik heb daarna handmatig de bestanden vervangen door de originele exemplaren en een nieuwe scrub gedaan maar de bestanden blijven corrupt.

Vraag 1: Hoe fix ik de mislukte replace actie van gptid/a98f6fd1-c840-11e5-8728-0cc47a6c12ea.

code:

  pool: freenas-boot
 state: DEGRADED
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 1K in 0 days 00:58:16 with 4 errors on Thu Sep 19 00:14:47 2019
config:

        NAME                                              STATE     READ WRITE CKSUM
        freenas-boot                                      DEGRADED     0     0     8
          mirror-0                                        DEGRADED     0     0    16
            replacing-0                                   DEGRADED     0     0    16
              gptid/a98f6fd1-c840-11e5-8728-0cc47a6c12ea  DEGRADED     0     0    39  too many errors
              da8p2                                       ONLINE       0     0    16
            da9p2                                         ONLINE       0     0    16

Vraag 2: Wat moet ik doen om de corrupte bestanden te fixen:

code:

        freenas-boot/ROOT/11.2-U6@2018-12-31-12:22:48:/usr/local/www/dojo/dojox/form/_HasDropDown.js.uncompressed.js
        freenas-boot/ROOT/11.2-U6@2018-12-31-12:22:48:/usr/local/www/dojo/dojox/form/_RangeSliderMixin.js
        freenas-boot/ROOT/11.2-U6@2018-12-31-12:22:48:/usr/local/www/dojo/dojox/form/_RangeSliderMixin.js.consoleStripped.js
        freenas-boot/ROOT/11.2-U6@2018-12-31-12:22:48:/usr/local/www/dojo/dojox/form/_RangeSliderMixin.js.uncompressed.js

[DataGhost]

Corrupte bestanden kan je alleen maar fixen door ze weg te gooien en daarna weer te scrubben. Aangezien ze in een snapshot staan moet je alle snapshots met die versie van het bestand erin weggooien, of leren leven met die errors.

[cyspoz]

Yes dat was meteen de oplossing voor beide problemen, na opschonen van de snapshots en een scrub zijn de corrupte bestanden weg en is tevens de replace actie voltooid. Nu heb ik weer een healthy boot met tevens bescherming tegen gegevens verlies.

[nero355]

DirkZzZ schreef op maandag 15 juli 2019 @ 23:02:
Mogelijk ook interessant voor de slopers onder ons; 8TB voor 135 euro. (Wel even letten op PWDIS en TLER)
8TB WD My Book

Ze zijn weer voor € 139 tekoop!

* nero355 gaat eens kijken hoeveel van die gekke dingen straks in het pakketje moeten zitten...

[Loekie]

Enig idee welke white labels daar in zitten? De Ezaz of emaz (blue/green whitelabel vs red whitelabel)?

[nero355]

Loekie schreef op zondag 22 september 2019 @ 16:41:
Enig idee welke white labels daar in zitten? De Ezaz of emaz (blue/green whitelabel vs red whitelabel)?

Voor zover ik heb begrepen de WD Red variant genaamd WD80EZZX en EZAZ, want deze worden in verschillende Customer Reviews genoemd @ Amazon

[unezra]

Hmmm.
Ik ben mijn nieuwe thuisserver aan het ontwerpen en wat last-minute beslissingen aan het nemen.

Qua disks heb ik, voor mijn data, een aantal 5T schijven tot mijn beschikking. (Daarnaast nog 2 SSD's voor het OS en 2 NVMe's die ik in ga zetten als read/write cache.)

Qua disk configuratie van de 5T's had ik eigenlijk min of meer besloten te gaan voor een aantal losse mirrors te gaan omdat dat lekker overzichtelijk is. Uitgaande van 4 disks, dus 2 losse 5T mirrors, totale netto capaciteit 10T.

Andere optie is een mirrored stripe, 4x5T. Totale capaciteit ook 10T en iets hogere snelheden.

RAIDZ1 had ik min of meer uitgesloten wegens traag.

Vanochtend toch even wat onderzoek gedaan en nu zie ik zit:
https://calomel.org/zfs_raid_speed_capacity.html

Blijkt, RAIDZ1 lijkt eigenlijk nauwelijks trager dan een mirrored stripe (al staat er geen 4-disk config tussen), maar levert bij 4 disks wel 15T netto op en bij 5 disks 20T. Ofwel, maar 1 disk verlies.

Klopt dit en moet ik misschien tóch kijken naar RAIDZ1 over 4 of 5 disks?

[FireDrunk]

RAIDZ1 is voor sequentieel gebruik ongeveer even snel als mirrors. Verschil zit hem vooral in IOPS.
Als het een pure data opslag bak is (waar ik wel vanuit ga), zou ik me er niet te druk om maken.
Overigens zou ik wel even opletten met je stripe verlies bij 4 disks. Dat kan je kleiner maken door de recordszie groter te zetten, maar moet je wel doen voordat je er data op prakt

[unezra]

FireDrunk schreef op maandag 23 september 2019 @ 11:28:
RAIDZ1 is voor sequentieel gebruik ongeveer even snel als mirrors. Verschil zit hem vooral in IOPS.
Als het een pure data opslag bak is (waar ik wel vanuit ga), zou ik me er niet te druk om maken.
Overigens zou ik wel even opletten met je stripe verlies bij 4 disks. Dat kan je kleiner maken door de recordszie groter te zetten, maar moet je wel doen voordat je er data op prakt

Het word een machine met Proxmox (PVE) en maximaal een paar handen vol, wisselend belaste, Linux en FreeBSD vm's.

Een van die vm's gaat voor NAS spelen. (Weet nog niet op welke manier precies, wel dat het een vm of een container word met iets van Samba op de achtergrond.)

Op dit moment heb ik nog 2 losse PVE hypervisors en 1 losse NAS, allemaal Microserver Gen8 machines met 16G. Ik heb goede hoop komend weekend mijn nieuwe server te bouwen op basis van een Ryzen 5 3600, die in zijn eentje alle 3 de huidige Microservers gaat vervangen. (Dus geen losse NAS meer, maar alle storage lokaal.)

Qua load is het allemaal niet heel spannend, het is in principe privé gebruik. Wel met een aantal externe websites en een spam/virusfilter (Proxmox Mail Gateway) er op.

Veranderd dat nog wat aan de situate?

[CurlyMo]

@unezra je VM's gaan toch op je SSD's draaien. Puur OS performance zal dus prima zijn. Voor de data die je tussen je VM's uitwisselt zou ik me inderdaad ook niet druk maken over performance.

[unezra]

CurlyMo schreef op maandag 23 september 2019 @ 11:58:
@unezra je VM's gaan toch op je SSD's draaien. Puur OS performance zal dus prima zijn. Voor de data die je tussen je VM's uitwisselt zou ik me inderdaad ook niet druk maken over performance.

Het meerendeel van de vm's gaat gewoon op mijn HDD's.

Ik heb 2x 256G SATA SSD er in voor het OS en misschien een paar vm's die niet al te groot zijn maar wel gebaat bij wat meer IO performance. De rest gaat allemaal op de HDD's. De NVMe's zijn zuiver voor caching aangeschaft.

Thing is, ik heb die HDD's nog liggen en de huidige performance die ik nu haal met 4x5T in een mirrored stripe, over een aantal etherchannels, via ZFS, is in principe voldoende. Ik ga er dus hoe dan ook flink op vooruit.

[CurlyMo]

unezra schreef op maandag 23 september 2019 @ 12:02:
[...]


Het meerendeel van de vm's gaat gewoon op mijn HDD's.

Ik heb 2x 256G SATA SSD er in voor het OS en misschien een paar vm's die niet al te groot zijn maar wel gebaat bij wat meer IO performance. De rest gaat allemaal op de HDD's. De NVMe's zijn zuiver voor caching aangeschaft.

Hoeveel ruimte heeft een VM nodig dat je ook je HDD's nog nodig hebt? Bij 256GB kan je 16 VM's van 16GB kwijt Voor een gemiddeld VM is 16GB toch zat?

[unezra]

CurlyMo schreef op maandag 23 september 2019 @ 12:40:
[...]
Hoeveel ruimte heeft een VM nodig dat je ook je HDD's nog nodig hebt? Bij 256GB kan je 16 VM's van 16GB kwijt Voor een gemiddeld VM is 16GB toch zat?

Oh, zeker, dus misschien dat ik daar later nog wel wat wijzigingen in door voer of bijvoorbeeld OS en data disks van de NAS vm splits. (Voordeel van PVE is dan ook wel weer dat ik dat live kan doen. Enige nadeel is dat ik indirect wel storage verlies want snapshots.)

Maar goed, dat ga ik laten afhangen van performance. Uitgangspunt is alles op de HDD's als dat genoeg performance oplevert.

Blijft dat ik wel benieuwd ben of de conclusies van genoemde URL kloppen en of het inderdaad niet of nauwelijks nadelig is 4x5T in RAIDZ1 te stoppen ipv mijn eerder voorgenomen losse mirrors of mirrored-stripe. 5T netto extra, bij voor mij weinig relevant performanceverlies ten opzichte van een mirrored strip en zelfs netto winst ten opzichte van mirrors (met name de schrijfsnelheid lijkt omhoog te gaan bij RAIDZ1), vind ik wel interessant.

[FireDrunk]

Ik heb ook een poos 3 * een mirror van 2 disks gehad. Snelheid was gemiddeld gezien met mijn gebruik (veel sequentiele transfers) slechter dan nu (RAIDZ2 pool). In RAIDZ2 schrijven er 4 disks tegelijk 'unieke' data. In de 3 mirrors zijn dat er maar 3.

Lezen was de mirror denk ik iets sneller omdat er meer koppen tegelijk konden lezen, maar was niet merkbaar in de praktijk. In mijn gebruikspatroon wordt er niet super veel op maximale snelheid gelezen, behalve misschien tijdens wat PAR2 werkzaamheden, maar die zijn weer CPU bound, dus meh.

[unezra]

FireDrunk schreef op maandag 23 september 2019 @ 14:33:
Ik heb ook een poos 3 * een mirror van 2 disks gehad. Snelheid was gemiddeld gezien met mijn gebruik (veel sequentiele transfers) slechter dan nu (RAIDZ2 pool). In RAIDZ2 schrijven er 4 disks tegelijk 'unieke' data. In de 3 mirrors zijn dat er maar 3.

Lezen was de mirror denk ik iets sneller omdat er meer koppen tegelijk konden lezen, maar was niet merkbaar in de praktijk. In mijn gebruikspatroon wordt er niet super veel op maximale snelheid gelezen, behalve misschien tijdens wat PAR2 werkzaamheden, maar die zijn weer CPU bound, dus meh.

Heb je ook ervaring met / kun je iets zeggen over mijn specifieke 3 scenario's?

- Losse 2x5T mirrors
- 4x5T in mirrored stripe
- 4x5T in RAIDZ1

Uitgangspunt is in mijn geval nog steeds 4 disks, dan kan ik dit aantal namelijk mooi gelijk houden met het aantal disks dat in mijn HP Microserver past. (Ik heb er 3, 1 daarvan wil ik in gaan zetten om dmv sanoid/syncoid backups te maken. Daarvoor zet ik bestaande disks in. Toeval wil dat ik 11 of 12 van die 5T's in huis heb.)

Sanoid: https://github.com/jimsalterjrs/sanoid

Op basis van genoemde URL - https://calomel.org/zfs_raid_speed_capacity.html - lijkt het of RAIDZ1 op 4 disks, wel eens een heel goed compromis kan zijn. (Al komt net die case niet voor, ze doen RAIDZ1 op 3, 5 en meer disks.) Voor mij is de verrassing dat zowel lees- als schrijfsnelheid omhoog gaan en bijna de snelheid van een mirrored stripe halen, terwijl de capaciteit niet n+n is, maar n+1, en ik dus met 4x5T, geen 10T netto, maar 15T netto over hou.

De grootste consessie is dat er in een RAIDZ1 echt maar 1 disk kapot mag gaan én dat resilvers duurder zijn dan bij een mirror of mirrored stripe. Ze duren langer en belasten het systeem veel zwaarder.

Losse mirrors zijn heel handig, maar de schrijfsnelheid is die van 1 disk, alleen de leessnelheid gaat omhoog. Ook is het geen continuous dataset. Voor mijn use case geen ramp, maar het betekend wel zorgvuldiger plannen dan met 10T of 15T continuous.

Qua CPU power en geheugen heb ik vooralsnog flink over. Er komt een Ryzen 5 3600 in met 64G geheugen, terwijl ik op dit moment rond de 20G geheugen gebruik. Kortom, ZFS heeft voorlopig de ruimte. Daarbij ga ik direct caching aanzetten op 2 stuks NVMe. (Die ga ik partitioneren, zodat de writecache in mirror kan, readcache in stripe. Optimale performance voor beiden.)

Het board en CPU kunnen naar 128G. Doe ik nu niet omdat ik 64G heb liggen, maar op termijn kan ik van 16G naar 32G modules toe.

Absolute snelheid is minder kritiek, alles draait nu op een stel G1610T CPU's en alle data staat op mijn NAS die met 2x GBit voor NFS aan mijn hypervisors hangt. Die snelheid lijkt vooralsnog voldoende, maar met lokale disks ga ik er alleen maar op vooruit. Waar ik nu naar zoek, is het beste compromis tussen snelheid, dataveiligheid en opslagcapaciteit.

[FireDrunk]

Write en Readcache SLOG & L2ARC op dezelfde SSD is niet heel verstandig denk ik. De SLOG zal je SSD's write queue zwaar belasten omdat dat allemaal pure QD=1 SYNC writes zijn. Dat zorgt er dus voor dat tijdens die writes je L2ARC niet geupdatet kan worden omdat de queue 'gelocked' is.

Ik durf niet met zekerheid te zeggen dat het echt significante / merkbare effecten op gaat leveren, maar ik verwacht van wel.

Wel kan je je L2ARC op metadata only zetten voor snelle zoektijden naar directories en files, maar een (veel) lagere belasting qua writes.

---
Over je eerste vraag, ik heb bijna al die setups wel een keer in mijn leven gedraaid, of je dat 'ervaring' kan noemen is relatief

Persoonlijk zou ik gaan voor snel genoeg, en me daar allemaal niet te druk over maken.
Zo is een SLOG (het is geen writecache ) super leuk, maar is het *echt* nodig? Of kan je toe met sync=disabled bijvoorbeeld.
Als je geen UPS hebt, is een writecache sowieso gevaarlijk met consumer SSDs en heb je sowieso iets met supercaps nodig. Als het kleine risico van stroomuitval voor jou sowieso geen issue is, zou ik lekker met sync=disabled draaien. Betere performance dan een SLOG op SSD, en net zo veilig (lees: risico is gelijk).

[ Voor 39% gewijzigd door FireDrunk op 23-09-2019 15:57 ]

[unezra]

FireDrunk schreef op maandag 23 september 2019 @ 15:52:
Write en Readcache op dezelfde SSD is niet heel verstandig denk ik. De writecache zal je SSD's write queue zwaar belasten omdat dat allemaal pure QD=1 SYNC writes zijn. Dat zorgt er dus voor dat tijdens die writes je ReadCache niet geupdatet kan worden omdat de queue 'gelocked' is.

Ik durf niet met zekerheid te zeggen dat het echt significante / merkbare effecten op gaat leveren, maar ik verwacht van wel.

Wel kan je je readcache op directory only zetten voor snelle zoektijden naar directories en files, maar een (veel) lagere belasting qua writes.

Hmm.

De ellende is dat het voor zover ik weet onverstandig is je writecache NIET op een mirror te zetten. Readcache maakt niet uit, als ik het goed begrepen heb.

Ik heb daarin een paar scenario's:

- Writecache of readcache op een partitie van mijn SATA SSD's (weet niet of ik kan partitioneren via de PVE installer enof ik dat een fijn idee vind, maar het kan), de ander op mijn NVMe's
- Writecache of readcache op 1 of meer losse SATA SSD's (kan in de kast, betekend wel dat ik sneller naar een HBA moet grijpen, ik heb "maar" 8x SATA on-board waar ik er nu direct 6 van in zet, ik heb er nog 2 over, in dit scenario 1)
- Writecache en readcache allebei op een losse NVMe (snel, maar dus geen mirror op mijn writecache)

Dus ja, de vraag is dan wat het beste compromis is, of dat ik voorlopig gewoon het eerdere scenario aan houd en pas als ik performance issues krijg, een van de andere zaken uit voer. Het is een extratje, oorspronkelijk plan was helemaal geen read/write cache op SSD te doen maar er zitten nu eenmaal 2 NVMe slots op dat board, wat het interessant maakt die te gebruiken.

Ik heb ook niet de snelste NVMe's aangeschaft. Voor wat ik er mee wil lijkt dit in ieder geval prima en die machine is al veel duurder geworden dan ik van plan was...

Deze: pricewatch: Corsair Force MP300 120GB

[FireDrunk]

Die SSD's zijn absoluut ongeschikt voor gebruik als SLOG, dus dat zou ik gewoon uit je hoofd zetten. Ofwel geen SYNC (sync=disabled), of gewoon default laten.

Die SSD gebruikt een Phison controller, welke geen lokaal DRAM heeft, maar een Host Buffer gebruikt.
Dat betekend dat hij zijn lokale mapping table (welke bitjes staan waar, en welk write amplification algoritme moet ik toepassen) allemaal in het primaire geheugen van je machine gebeurt.

Mag jij raden wat er gebeurt bij een vervelende power failure, op een verkeerd moment

Je kan beide SSD's als losse L2ARC inzetten voor de 'leuk', verder zou ik de setup standaard laten.

[unezra]

FireDrunk schreef op maandag 23 september 2019 @ 16:07:
Die SSD's zijn absoluut ongeschikt voor gebruik als SLOG, dus dat zou ik gewoon uit je hoofd zetten. Ofwel geen SYNC (sync=disabled), of gewoon default laten.

Die SSD gebruikt een Phison controller, welke geen lokaal DRAM heeft, maar een Host Buffer gebruikt.
Dat betekend dat hij zijn lokale mapping table (welke bitjes staan waar, en welk write amplification algoritme moet ik toepassen) allemaal in het primaire geheugen van je machine gebeurt.

Mag jij raden wat er gebeurt bij een vervelende power failure, op een verkeerd moment

Je kan beide SSD's als losse L2ARC inzetten voor de 'leuk', verder zou ik de setup standaard laten.

Crap.

Dus dat is óf als L2ARC inzetten, óf als OS disk, óf ze omruilen voor iets beters (en dus duurders)?

Ben meteen even wat gaan rondneuzen, dit lijkt dan een optie:
pricewatch: Transcend 220S 256GB
(Is wel *way* groter dan ik nodig heb en €43 duurder als ik er 2 koop, maar dat is nog te overzien.)

Volgens Transcend heeft 'ie wel DRAM, de 110 series niet.
https://www.transcend-info.com/Products/No-991

Op de website van Marvell kom ik wel wat tegen (DRAM based PCIe Gen 3 NVMe SSD Controller (88SS1084 and 88SS1100) maar die komen dan weer niet voor in de pricewatch, dus daar kan ik niet op selecteren.

Als ik in de pricewatch probeer 8MByte of meer cache toe te voegen, komt juist mijn Corsair Force er weer uit.

Da's een tegenvaller, ik moet zeggen dat ik dáár echt compleet niet aan heb gedacht. Ik heb me eerder wel ingelezen over de SLOG en L2ARC, maar zelfs in de primer komt niet voor dat DRAM op een SSD een must is, enkel dat de voorkeur uit gaat naar een battery backed DRAM module (I know, compleet ander beest) óf een snelle SSD. (Fin, snel is zo'n NVME wel. Zelfs de relatief trage Corsair Force met 1.520MB/s lezen en 460MB/s schrijven.)

Stel dat ik alsnog mijn SLOG op een NVMe wil zetten, is er een betaalbare oplossing? Of is het heel snel heel duur en niet meer interessant voor wat in feite niet meer is dan een hobbyserver met wat websites, wat interne zaken, etc. (Ofwel, kan ik beter zoals je zegt enkel de L2ARC op die NVMe's zetten omdat het kan, voor de leuk en verder vooral het hele idee van een SLOG laten voor wat het is?)

[Kuusj]

FireDrunk schreef op maandag 23 september 2019 @ 16:07:
Die SSD's zijn absoluut ongeschikt voor gebruik als SLOG, dus dat zou ik gewoon uit je hoofd zetten. Ofwel geen SYNC (sync=disabled), of gewoon default laten.

Die SSD gebruikt een Phison controller, welke geen lokaal DRAM heeft, maar een Host Buffer gebruikt.
Dat betekend dat hij zijn lokale mapping table (welke bitjes staan waar, en welk write amplification algoritme moet ik toepassen) allemaal in het primaire geheugen van je machine gebeurt.

Mag jij raden wat er gebeurt bij een vervelende power failure, op een verkeerd moment

Je kan beide SSD's als losse L2ARC inzetten voor de 'leuk', verder zou ik de setup standaard laten.

Mijn MX100 256GB (Docker/random zooi drive voor mijn NAS) heeft daar powercaps voor om zo nog even alles weg te schrijven als de stroom uit valt. Dat is misschien ook iets om naar te kijken @unezra
Tevens ouderwetsch MLC geheugen dus gaat niet zo snel stuk, alhoewel ik al veel vaker kapotte HDD's heb gehad dan SSD's...

[unezra]

Kuusj schreef op maandag 23 september 2019 @ 18:37:
[...]
Mijn MX100 256GB (Docker/random zooi drive voor mijn NAS) heeft daar powercaps voor om zo nog even alles weg te schrijven als de stroom uit valt. Dat is misschien ook iets om naar te kijken @unezra
Tevens ouderwetsch MLC geheugen dus gaat niet zo snel stuk, alhoewel ik al veel vaker kapotte HDD's heb gehad dan SSD's...

Hmm.
Daar zeg je wat.

Ik heb een UPS thuis staan, waar in principe alles achter hangt. (Servers, switch, router, etc.)
Nu is dat ding nog standalone, puur voor het opvangen van powerdips, ik ben van plan met die nieuwe server die UPS wel aan mijn server te hangen, either via serial danwel netwerk. Dat haalt misschien wel een deel van het risico van een onverwachte powerdip weg. (Al heb ik op kantoor op een zeker moment meer last dan profijt van de UPSen gehad. Die UPSen gingen vaker plat dan de stroom.)

Zo'n bakje staat hier:
pricewatch: Eaton 5P 1550 Global Tower

Samen met de (veel te friggin' dure) netwerkkaart:
pricewatch: Eaton Netwerkkaart: Network Card-MS

Met mijn huidige setup levert dat een rundown op van 45 minuten, met de nieuwe hoop ik dik een uur te kunnen halen.

Maar goed, door het comment van @FireDrunk word ik nu wel wat nerveus of ik het risico moet nemen, of dat het onaanvaardbaar is. (En nee, snel zijn die dingen niet maar het is ook echt een experiment en het zijn juist de latency grafieken van het blog van Aaron Toponce die die SLOG zo interessant maken. Helemaal in mijn specifieke use-case, waar ik eigenlijk uitsluitend met vm's aan de slag ga.)

[Kuusj]

unezra schreef op maandag 23 september 2019 @ 18:44:
[...]


Hmm.
Daar zeg je wat.

Ik heb een UPS thuis staan, waar in principe alles achter hangt. (Servers, switch, router, etc.)
Nu is dat ding nog standalone, puur voor het opvangen van powerdips, ik ben van plan met die nieuwe server die UPS wel aan mijn server te hangen, either via serial danwel netwerk. Dat haalt misschien wel een deel van het risico van een onverwachte powerdip weg. (Al heb ik op kantoor op een zeker moment meer last dan profijt van de UPSen gehad. Die UPSen gingen vaker plat dan de stroom.)

Zo'n bakje staat hier:
pricewatch: Eaton 5P 1550 Global Tower

Samen met de (veel te friggin' dure) netwerkkaart:
pricewatch: Eaton Netwerkkaart: Network Card-MS

Met mijn huidige setup levert dat een rundown op van 45 minuten, met de nieuwe hoop ik dik een uur te kunnen halen.

Maar goed, door het comment van @FireDrunk word ik nu wel wat nerveus of ik het risico moet nemen, of dat het onaanvaardbaar is. (En nee, snel zijn die dingen niet maar het is ook echt een experiment en het zijn juist de latency grafieken van het blog van Aaron Toponce die die SLOG zo interessant maken. Helemaal in mijn specifieke use-case, waar ik eigenlijk uitsluitend met vm's aan de slag ga.)

Je moet jezelf afvragen wat je precies voor een risico loopt. De kans dat de stroom uit valt is al heel klein, en dan moeten er ook nog een paar andere dingen tegelijk gebeuren wil je er echt schade van ondervinden. Stel nu dat je dagelijks een snapshot van je VM's laat wegschrijven naar een backup ben je in het aller-ergste geval 1 dag van je VM's kwijt.

De data die ik echt niet kwijt wil (foto's/video's) heb ik toch nog op 2 cold storage disken staan buiten de 'hete' kopie op een Raid5 array op mijn NAS. Het risico dat het hele zaakje klapt en ik mijn films en series dan kwijt ben neem ik dan wel.

Maar goed, ik weet jou situatie natuurlijk niet. Als er mission critical VM's draaien zou ik het risico niet nemen nee, maar als mijn Dockertjes met Plex en Unifi het loodje leggen kan ik daar geen traan om laten.

[unezra]

Kuusj schreef op maandag 23 september 2019 @ 18:50:
[...]
Je moet jezelf afvragen wat je precies voor een risico loopt. De kans dat de stroom uit valt is al heel klein, en dan moeten er ook nog een paar andere dingen tegelijk gebeuren wil je er echt schade van ondervinden. Stel nu dat je dagelijks een snapshot van je VM's laat wegschrijven naar een backup ben je in het aller-ergste geval 1 dag van je VM's kwijt.

De data die ik echt niet kwijt wil (foto's/video's) heb ik toch nog op 2 cold storage disken staan buiten de 'hete' kopie op een Raid5 array op mijn NAS. Het risico dat het hele zaakje klapt en ik mijn films en series dan kwijt ben neem ik dan wel.

Maar goed, ik weet jou situatie natuurlijk niet. Als er mission critical VM's draaien zou ik het risico niet nemen nee, maar als mijn Dockertjes met Plex en Unifi het loodje leggen kan ik daar geen traan om laten.

Een van de dingen die ik al jaren roep, maar nu écht ga verwezenlijken, zijn backups.
Ik ben die ICTer die tegen iedereen roept dat je altijd backups moet hebben, maar ze zelf niet heeft.
(Wel maak ik dagelijks snapshots en staat alle belangrijke data op een mirrored stripe, maar RAID is uiteraard geen backup, snapshots zijn dat ook niet.)

Omdat ik letterlijk alle noodzakelijke hardware al in huis heb, heb ik nu geen excuus meer en ga ik Sanoid/Syncoid (waarschijnlijk) deployen op mijn nieuwe hypervisor. Die mag zijn data periodiek (dagelijks, om de dag) naar een Microserver blazen. (De grootste twijfel is nog waar ik dat ding fysiek ga plaatsen. In huis, of in de schuur.)

Dus inderdaad, zou ik net tegen die conditie aanlopen dat het mis gaat en ZFS kan dat niet oplossen met een scrub (scrubs zijn geweldig, het is een van de redenen waarom ik ZFS draai, ik had een keer een HBA met brakke firmware, dankzij ZFS nul corruptie), ben ik in principe hooguit een dag, 2 dagen data kwijt.

Dat is aanvaardbaar.

Het is ook echt letterlijk mijn privé server. De website van mijn slapende stichting draait er op, mijn thuisdata. De data is wel belangrijk, maar wijzigt in de regel zo weinig, dat een paar dagen of zelfs een week terug zelden een ramp is.

[FireDrunk]

@unezra de goedkoopste oplossing is 'tweedehands' enterprise ssd's.

Zoiets: V&A aangeboden: Intel DC D3-S4510 2,5" 240GB, nieuw in verpakking! Enterpise ...

Die dingen zijn zeer geschikt voor SLOG en L2ARC.

Nogmaals: bedenk gewoon of je wel echt sync nodig hebt. Zonder sync raakt ZFS zelf nog steeds niet corrupt, je verliest hooguit de laatste secondes aan data. Met regelmatige snapshots van VMs voor het geval dat hoef je je echt niet zo druk te maken.

Mijn idee zou zijn, 4 disk RAIDZ, mirrored NVMe ssds voor os en een deel L2ARC, sync uit voor de filesystems waar het niet nodig is. De rest van de poorten gewoon ongemoeid laten. Je kan dan altijd in een later stadium (lees: over een paar jaar) een setje 18TB disks in mirror zetten als je ruimte tekort komt.

[CurlyMo]

FireDrunk schreef op maandag 23 september 2019 @ 19:21:
Zoiets: V&A aangeboden: Intel DC D3-S4510 2,5" 240GB, nieuw in verpakking! Enterpise ...

Ik heb hier van die Intel Enterprise SSD's in mijn NAS gehad en merkbare verschil was 0

[FireDrunk]

I rest my case
Ze zijn vooral veilig

[nero355]

Kuusj schreef op maandag 23 september 2019 @ 18:37:
Mijn MX100 256GB (Docker/random zooi drive voor mijn NAS) heeft daar powercaps voor om zo nog even alles weg te schrijven als de stroom uit valt. Dat is misschien ook iets om naar te kijken @unezra
Tevens ouderwetsch MLC geheugen dus gaat niet zo snel stuk, alhoewel ik al veel vaker kapotte HDD's heb gehad dan SSD's...

Zolang het niet de DC serie is van Crucial of gewoon een Micron branded SSD is heeft deze alleen bescherming voor de data die al op de SSD staat en voorkomt op die manier corruptie van de SSD

De data in de buffer ben je dus op zo'n moment kwijt!!!


Als je 100% beschermde SSD's wil hebben dan kom je al gauw op zoiets uit :
- pricewatch: Intel DC S3710 2,5" 200GB
- pricewatch: Intel DC D3-S4510 2,5" 240GB
- pricewatch: Intel DC D3-S4610 480GB
- pricewatch: Intel DC S3500 (2,5") 240GB
- pricewatch: Intel DC S3520 2,5" 960GB
enz...


Of natuurlijk : pricewatch: Intel Optane 900P PCI-e 280GB

[Kuusj]

nero355 schreef op maandag 23 september 2019 @ 19:56:
[...]

Zolang het niet de DC serie is van Crucial of gewoon een Micron branded SSD is heeft deze alleen bescherming voor de data die al op de SSD staat en voorkomt op die manier corruptie van de SSD

De data in de buffer ben je dus op zo'n moment kwijt!!!


Als je 100% beschermde SSD's wil hebben dan kom je al gauw op zoiets uit :
- pricewatch: Intel DC S3710 2,5" 200GB
- pricewatch: Intel DC D3-S4510 2,5" 240GB
- pricewatch: Intel DC D3-S4610 480GB
- pricewatch: Intel DC S3500 (2,5") 240GB
- pricewatch: Intel DC S3520 2,5" 960GB
enz...


Of natuurlijk : pricewatch: Intel Optane 900P PCI-e 280GB

Ja goed klopt Maar zoals ik zei: voor mij persoonlijk is dat het echt niet waard, maar ik kan me voorstellen dat je wel '100%' zekerheid wil.

[nero355]

Kuusj schreef op maandag 23 september 2019 @ 19:59:
Ja goed klopt

Maar zoals ik zei: voor mij persoonlijk is dat het echt niet waard, maar ik kan me voorstellen dat je wel '100%' zekerheid wil.

Zelfs mijn Games staan op een Crucial M500 van 960 GB die ik heb gekocht ver nadat het een courant model was!

OS en belangrijke data staan nog op oude Intel 320's van 120 en 300 GB

[unezra]

FireDrunk in "Het grote ZFS topic"

FireDrunk schreef op maandag 23 september 2019 @ 19:21:
@unezra de goedkoopste oplossing is 'tweedehands' enterprise ssd's.

Zoiets: V&A aangeboden: Intel DC D3-S4510 2,5" 240GB, nieuw in verpakking! Enterpise ...

Die dingen zijn zeer geschikt voor SLOG en L2ARC.

Lever je dan niet enorm in op snelheid omdat het SATA is en geen NVMe?
Dat was de reden waarom ik die NVMe's had aangeschaft voor SLOG en L2ARC en mijn OS op 2 normale SSD's.

Deze:
pricewatch: Transcend SSD230S 256GB

Grappig genoeg hebben net die wel DRAM cache volgens de website:
https://www.transcend-info.com/Products/No-756

(Ik heb ook nog zijn kleine broertje, de 128G versie, thuis liggen.)

Als die DRAM cache zo kritiek is, kan ik dan de conclusie trekken dat ik als ik écht een SLOG op SSD wil zetten, ik tegen mijn verwachting in, beter het OS of een paar VM's op mijn NVMe's kan zetten en de Transcend SSD's kan inzetten voor SLOG en L2ARC?

Of, even helemaal terug naar de basis:
FireDrunk in "Het grote ZFS topic"

SLOG laten voor wat het is, sync disablen voor een stuk performancewinst (met een beperkt risico wegens UPS) en eventueel laten omdat het toch niet extern staat. (Of het uitproberen met en zonder, kijken waar ik me het beste bij voel en dat kiezen, wetende dat de risico's van SYNC uitzetten aanvaardbaar zijn.)

Nogmaals: bedenk gewoon of je wel echt sync nodig hebt. Zonder sync raakt ZFS zelf nog steeds niet corrupt, je verliest hooguit de laatste secondes aan data. Met regelmatige snapshots van VMs voor het geval dat hoef je je echt niet zo druk te maken.

Juist.

Mijn idee zou zijn, 4 disk RAIDZ, mirrored NVMe ssds voor os en een deel L2ARC, sync uit voor de filesystems waar het niet nodig is. De rest van de poorten gewoon ongemoeid laten. Je kan dan altijd in een later stadium (lees: over een paar jaar) een setje 18TB disks in mirror zetten als je ruimte tekort komt.

Wat betreft dat laatste is de gedachte om over een paar jaar gewoon de 5T's te vervangen door grotere, snellere exemplaren of tijdelijk een paar disks er bij die ik mogelijk toch nog ergens heb zwerven tegen die tijd.

Dit is wel een leuke puzzel. Jij en allen dank voor deze hersenkraker en ik ben blij dat ik vanochtend toch even voordat ik ga bouwen (ik hoop morgen, overmorgen alle essentiële componenten binnen te hebben), wat onderzoek heb gedaan en deze discussie heb gestart. Het levert mij heel veel nieuwe inzichten op.

Ik had werkelijk nooit verwacht terug te moeten komen op mijn beslissing voor losse mirrors te gaan, maar neig nu sterk naar RAIDZ1 met 4 disks. (Vanwege de hogere lees- en schrijfsnelheden én vanwege de extra 5T die ik daardoor gratis heb.) Ook had ik zonder dit, zonder pardon de SLOG op die NVMe's gegooid terwijl nu net dát iets is dat ik misschien helemaal niet ga doen, of op mijn SATA SSD's als die idd de benodigde DRAM cache hebben.

De disks die ik heb en morgen worden geleverd gaan er sowieso wel in maar het is wel interessant de functie nog even goed te overdenken voordat ik de machine in productie neem. Ik hoop over niet al te lange tijd de data 1:1 overgezet te hebben van mijn huidige setup (ik ga de vm's 1:1 migreren, herinrichten doe ik wel op de nieuwe server) dus wil vrij snel tot een definitieve inrichting komen.

[CurlyMo]

unezra schreef op maandag 23 september 2019 @ 20:34:
Lever je dan niet enorm in op snelheid omdat het SATA is en geen NVMe?
Dat was de reden waarom ik die NVMe's had aangeschaft voor SLOG en L2ARC en mijn OS op 2 normale SSD's.

Je kijkt naar de verkeerde snelheid. Je moet je focussen op de QD1. Die is bij de meeste consumenten SSD's dramatisch

Of, even helemaal terug naar de basis:

En niet op voorhand je zo extreem focussen op performance. Stel eerst eens vast dat je daadwerkelijk een bottleneck hebt voordat je je hier druk om maakt. Ik verwacht dat die bottleneck er niet of nauwelijks zal zijn.

[FireDrunk]

Tenzij je VMs op spinning disks zet, dat zuigt apeballen

[unezra]

CurlyMo schreef op maandag 23 september 2019 @ 20:38:
[...]
Je kijkt naar de verkeerde snelheid. Je moet je focussen op de QD1. Die is bij de meeste consumenten SSD's dramatisch

Die staat helaas ook niet in de pricewatch. Wel QD32.
Die is dan weer niet zo dramatisch, vergeleken met genoemde Intel.

Vergeleken met een echte enterprise SSD zie je idd wel de verschillen. Maar ja, daar is de prijs dan ook naar. (Ik heb er willekeurig even eentje geprikt.)

https://tweakers.net/pric...1;666119;1248021;1113263/

[...]
En niet op voorhand je zo extreem focussen op performance. Stel eerst eens vast dat je daadwerkelijk een bottleneck hebt voordat je je hier druk om maakt. Ik verwacht dat die bottleneck er niet of nauwelijks zal zijn.

Was ook ooit het idee. Gewoon 2x SATA SSD voor het OS en misschien een enkele vm of container, 4x 5T voor mijn vm's en alle data en klaar. Ergens bedacht ik me als ik dan tóch 2 NVMe slots on-board heb, ik die wel meteen kon vullen met iets nuttigs.

Zo is het een beetje ontstaan. Het board heeft het, dus wil ik het nuttig inzetten. (Terwijl het ten opzichte van nu, met alles via NFS via 2x 1GBit ethernet, hoe dan ook veel sneller gaat zijn.) Misschien ben ik daar wat te snel geweest.

Inmiddels ook ontdekt dat er inderdaad een optie in de pricewatch is "Stroomverliesbescherming", zit goed verstopt. "Technische Specificaties" --> "SSD Eigenschappen" --> "Stroomverliesbescherming".

Krijg je dit lijstje:
categorie: Solid state drives

Met, bizar genoeg, deze nog best betaalbare NVMe's met relatief hoge IOPS:
pricewatch: Samsung PM981 256GB
pricewatch: Samsung PM981 512GB

*oef*

FireDrunk schreef op maandag 23 september 2019 @ 20:59:
Tenzij je VMs op spinning disks zet, dat zuigt apeballen

Och, dat valt ook nog wel mee. Privé heb ik dat nu ook (zie boven), zelfs op kantoor hebben we dat.
Performt op kantoor prima. Wel meer spindles (72 in totaal, 2x "12+24" voor rond de 70 vm's), maar geen SSD caching, wel NFS en WAFL (NetApp) als filesystem.

Ja, dat kan sneller maar ook dat performt naar behoefte.

[CurlyMo]

unezra schreef op maandag 23 september 2019 @ 21:04:
[...]
Die staat helaas ook niet in de pricewatch. Wel QD32.
Die is dan weer niet zo dramatisch, vergeleken met genoemde Intel.

Verschil ga je niet merken.

Vergeleken met een echte enterprise SSD zie je idd wel de verschillen. Maar ja, daar is de prijs dan ook naar. (Ik heb er willekeurig even eentje geprikt.)

Behalve in je portemonnee

Was ook ooit het idee. Gewoon 2x SATA SSD voor het OS en misschien een enkele vm of container, 4x 5T voor mijn vm's en alle data en klaar.

Doen! Echt. Dit is gewoon prima voor thuisgebruik.

[Kuusj]

unezra schreef op maandag 23 september 2019 @ 21:04:
[...]


Die staat helaas ook niet in de pricewatch. Wel QD32.
Die is dan weer niet zo dramatisch, vergeleken met genoemde Intel.

Vergeleken met een echte enterprise SSD zie je idd wel de verschillen. Maar ja, daar is de prijs dan ook naar. (Ik heb er willekeurig even eentje geprikt.)

https://tweakers.net/pric...1;666119;1248021;1113263/


[...]


Was ook ooit het idee. Gewoon 2x SATA SSD voor het OS en misschien een enkele vm of container, 4x 5T voor mijn vm's en alle data en klaar. Ergens bedacht ik me als ik dan tóch 2 NVMe slots on-board heb, ik die wel meteen kon vullen met iets nuttigs.

Zo is het een beetje ontstaan. Het board heeft het, dus wil ik het nuttig inzetten. (Terwijl het ten opzichte van nu, met alles via NFS via 2x 1GBit ethernet, hoe dan ook veel sneller gaat zijn.) Misschien ben ik daar wat te snel geweest.

Inmiddels ook ontdekt dat er inderdaad een optie in de pricewatch is "Stroomverliesbescherming", zit goed verstopt. "Technische Specificaties" --> "SSD Eigenschappen" --> "Stroomverliesbescherming".

Krijg je dit lijstje:
categorie: Solid state drives

Met, bizar genoeg, deze nog best betaalbare NVMe's met relatief hoge IOPS:
pricewatch: Samsung PM981 256GB
pricewatch: Samsung PM981 512GB

*oef*


[...]


Och, dat valt ook nog wel mee. Privé heb ik dat nu ook (zie boven), zelfs op kantoor hebben we dat.
Performt op kantoor prima. Wel meer spindles (72 in totaal, 2x "12+24" voor rond de 70 vm's), maar geen SSD caching, wel NFS en WAFL (NetApp) als filesystem.

Ja, dat kan sneller maar ook dat performt naar behoefte.

Ik heb in mijn main PC nog steeds een 840 EVO van 250GB. Die gaat nu 28TBW en 13.000 uur mee zonder 1 error, met deze specs:
- 540MB/s write
- 520MB/s read
- 97.000 IOPS random read (4K/32QD)
- 66.000 IOPS random write (4K/32QD)

In mijn laptop zit dit beestje: pricewatch: Corsair Force MP510 960GB
- 3480MB/s read
- 3000MB/s write
- 610.000 IOPS random read (4K/QD32)
- 570.000 IOPS random write (4K/QD32)

Eerlijk waar, het enige verschil wat ik merk is misschien hoe snel mijn PC opstart, en bij de transfers van grote files loopt de cache van de EVO vol/leeg en is de snelheid er echt uit. Maar goed, is ook een heel ander kaliber SSD. Ik zou me er niet zo'n zorgen over maken.

[unezra]

Ik ga d'r nog eens even heel goed over na denken en misschien die Corsair Force MP300 120GB's terug sturen binnen 14 dagen (lang leve WKOA). Ik heb d'r buiten deze setup ook niet echt nut voor en het is toch €72,- aan SSD's plus wat extra stroomverbruik. (5W in bedrijf.)

Ondertussen broeden of het zinvol is alsnog 2 stuks Samsung PM981 aan te schaffen. Die zijn dan wel wat duurder (en qua capaciteit belachelijk overspecced), maar zitten qua IOPS (welliswaar QD32, QD1 zegt de pricewatch niets over) vrij hoog.

Hoe dan ook, dat kan ik altijd later nog doen als uit onderzoek blijkt dat het nut gaat hebben.
Die NVMe slots lopen niet weg...

[CurlyMo]

unezra schreef op maandag 23 september 2019 @ 21:28:
Hoe dan ook, dat kan ik altijd later nog doen als uit onderzoek blijkt dat het nut gaat hebben.
Die NVMe slots lopen niet weg...

[nero355]

unezra schreef op maandag 23 september 2019 @ 21:04:
Inmiddels ook ontdekt dat er inderdaad een optie in de pricewatch is "Stroomverliesbescherming", zit goed verstopt. "Technische Specificaties" --> "SSD Eigenschappen" --> "Stroomverliesbescherming".

Krijg je dit lijstje:
categorie: Solid state drives

Ik zie daar een hoop SSD's die dat helemaal niet hebben of niet volledig

Met, bizar genoeg, deze nog best betaalbare NVMe's met relatief hoge IOPS:
pricewatch: Samsung PM981 256GB
pricewatch: Samsung PM981 512GB

En die Samsung's hebben het zeker weten niet als ik de foto's ervan opzoek, zoals bij de meeste Samsung modellen altijd het geval is!

[unezra]

nero355 schreef op dinsdag 24 september 2019 @ 17:03:
[...]
Ik zie daar een hoop SSD's die dat helemaal niet hebben of niet volledig

[...]
En die Samsung's hebben het zeker weten niet als ik de foto's ervan opzoek, zoals bij de meeste Samsung modellen altijd het geval is!

Mêh.
Dan is het dus echt niet goed uit de pricewatch te halen.

Tijd voor een request in Pricewatch
Enig idee hoe ik dat goed kan omschrijven, of iemand anders die daar een goede post voor kan maken?

Lijkt me wel iets dat érg zinvol is goed en eenvoudig uit de PW te kunnen halen.

[FireDrunk]

De optie zit goed in de PW, verwerking en controle is matig. Is meer history dan een fout in de PW.
Gewoon dubbelchecken op site van de fabrikant.
Doorgaans hebben alleen prosumer en enterprise grade SSDs de functionaliteit, met een paar uitzonderingen.

Zoiets kan ook, maar is minder geschikt vanwege PCIe poort gebruik.

[ Voor 30% gewijzigd door FireDrunk op 24-09-2019 18:10 ]