Gå til innhold

BSD/UnixBSD/UnixZFS - utvide et pool med nytt vdev?


Anbefalte innlegg

Si at man kjører en pool med 3*2TB i raidz1. Så etter en stund ønsker man mere plass og kjøper 3x4TB, kan man da lage en ny vdev og så legge til den poolen man allerede har laget?

Og da vil man totalt få 4TB + 8TB= 12TB?

 

Er helt ny på dette, så lurer på om jeg har forstått rett?

Lenke til kommentar
Videoannonse
Annonse

Si at man kjører en pool med 3*2TB i raidz1. Så etter en stund ønsker man mere plass og kjøper 3x4TB, kan man da lage en ny vdev og så legge til den poolen man allerede har laget?

Og da vil man totalt få 4TB + 8TB= 12TB?

 

Er helt ny på dette, så lurer på om jeg har forstått rett?

 

 

Ja du har forstått det rett. Du kan gjøre som du skisserer, men det er ikke anbefalt å mikse disks med forskjellig størrelse, selv om du holder samma størrelse i de forskjellige vdev.

 

Dersom du skal ha en pool med flere vdev, er det best med samma størrelse, antall disk og paritets level på alle vdev.

Det er også å foretrekke å lage poolen ferdig først som sist. Altså å ikke utvide den etter at du har fyllt den opprinnelige med data. Det har med ytelse å gjøre.

 

Du kan øke størrelsen på en pool ved å bytte ut alle disks med større disks. Dog litt tungvindt da du må bytte en av gangen.

Lenke til kommentar

Ja du har forstått det rett. Du kan gjøre som du skisserer, men det er ikke anbefalt å mikse disks med forskjellig størrelse, selv om du holder samma størrelse i de forskjellige vdev.

 

Dersom du skal ha en pool med flere vdev, er det best med samma størrelse, antall disk og paritets level på alle vdev.

Det er også å foretrekke å lage poolen ferdig først som sist. Altså å ikke utvide den etter at du har fyllt den opprinnelige med data. Det har med ytelse å gjøre.

 

Du kan øke størrelsen på en pool ved å bytte ut alle disks med større disks. Dog litt tungvindt da du må bytte en av gangen.

Men til hjemmebruk har ikke den lille ytelsesforskjellen noe som helst å si. ;)
Lenke til kommentar

Håper det går greit at jeg sniker meg inn her... sitter å leser litt om freenas selv for øyeblikket.

 

Mener å ha lest en plass (som jeg ikke husker igjen) at dersom en vdev ryker/krasjer så går det utover alle andre vdevs innenfor samme pool?

Medfører dette riktighet, eller er det bare den enkelte vdev som ryker?

Lenke til kommentar

Hei

 

Fant guiden jeg snakket om nå, i PDF-filen her: http://forums.freenas.org/index.php?threads/slideshow-explaining-vdev-zpool-zil-and-l2arc-for-noobs.7775/ på side 11 og 12.

Her står d:

"If any VDev in a zpool is failed, you will lose the entire zpool with no chance of partial recovery." og

"If any VDev in a zpool fails, then all data in the zpool is unavailable."

 

Jeg forstår det sånn at uansett hva de forskjellige vdevs innenfor samme pool består av, så ryker ALT i poolen om én vdev ryker?

 

 

Edit: Dette er da om en vdev ryker, ikke om en disk i en vdev ryker

Endret av omvik
Lenke til kommentar
  • 4 uker senere...

 

Ja du har forstått det rett. Du kan gjøre som du skisserer, men det er ikke anbefalt å mikse disks med forskjellig størrelse, selv om du holder samma størrelse i de forskjellige vdev.

 

Dersom du skal ha en pool med flere vdev, er det best med samma størrelse, antall disk og paritets level på alle vdev.

Det er også å foretrekke å lage poolen ferdig først som sist. Altså å ikke utvide den etter at du har fyllt den opprinnelige med data. Det har med ytelse å gjøre.

 

Du kan øke størrelsen på en pool ved å bytte ut alle disks med større disks. Dog litt tungvindt da du må bytte en av gangen.

Men til hjemmebruk har ikke den lille ytelsesforskjellen noe som helst å si. ;)

 

 

Ikke noe i veien å følge best practices selv om du er hjemme ;)

Lenke til kommentar
  • 3 uker senere...

Om du adder vdevs i en pool så fordrer det att du sjekker helsen til disker.

Sannsyligheten att 2 hdd`s ryker i et vdev er sjelden, men kan skje.

 

Da ryker som sagt hele pool.

 

nas4free eller freenas har jo s.m.a.r.t error report som sier noe om helsen på hdd`s

 

Er nok heller litt mer engstelig angående ZFS og none ECC kontra ECC :)

Endret av Lindsay
Lenke til kommentar

Uten ECC kan ZFS teoretisk sett gå inn i en selvdestruktiv loop som gjør mer skade enn hva et ikke-ZFS-system ville fått hvis samme feilen oppstod der. Og feil kan oppstå i ZFS uten at det faktisk er noe HDD-feil der, pga checksumming. http://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/

Men sannsynligheten for at dette inntreffer er uansett såpass liten at det kanskje ikke er verdt å gå rundt og engste seg for det. http://blog.brianmoses.net/2014/03/why-i-chose-non-ecc-ram-for-my-freenas.html

Lenke til kommentar

Du påstår at "ZFS har ingen effekt uten ECC". Men, ZFS er et solid og bra filsystem selv uten ECC, kanskje til og med bedre enn andre filsystemer på markedet. Din "ingen effekt" får det til å høres ut som om ZFS ikke virker uten ECC.

Derav logisk kortslutning i tenkingen.

Lenke til kommentar

Jo zfs fungerer som system uten ECC, men den funksjonen som zfs gir med selvreparerende filsystem har ingen effekt om det har oppståẗt feil under kopiering.

Og det er den unike funksjonen att det er selvreparerende som gjør zfs så genialt.

 

Da hjelper ikke scrub, duplisering eller what ever zfs gir.

 

 

Da må en om en kjører zfs uten ECC ha media som holder det samme innhold på et annet filsystem som UFS/EXT3 eller 4. Og så er det også en regel om att raid ikke er optimal backup heller.

Lenke til kommentar

Bli med i samtalen

Du kan publisere innhold nå og registrere deg senere. Hvis du har en konto, logg inn nå for å poste med kontoen din.

Gjest
Skriv svar til emnet...

×   Du har limt inn tekst med formatering.   Lim inn uten formatering i stedet

  Du kan kun bruke opp til 75 smilefjes.

×   Lenken din har blitt bygget inn på siden automatisk.   Vis som en ordinær lenke i stedet

×   Tidligere tekst har blitt gjenopprettet.   Tøm tekstverktøy

×   Du kan ikke lime inn bilder direkte. Last opp eller legg inn bilder fra URL.

Laster...
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...