Den "Store" unRAID tråden

[Gjest Slettet-jDflNq]

Å la de spinne hele tiden er faktisk bedre enn auto spindown. Disker slites ut mer av å spinnes opp konstant enn å spinne 24/7. Den eneste grunnen til å velge auto spindown er hvis du ønsker å spare strøm.

[Svar]

Virker som de lærde strides med om det sliter mye på en disk eller ikke, men alle er enige om at det sparer strøm

[Bjonness406]

Lar de spinne ned, bryr meg ikke så veldig. Bruker de ikke akkurat 24/7 heller. Kun når jeg ser på plex eller sikkerhetskopier dokumenter/bilder.

Har ikke forandret noen settings, så de spinner hele tiden. 

Endret 12. april 2016 av Bjonness406

[Svar]

Da var server nr2 på plass

[janfredrik]

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert 

 

[Bjonness406]

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert

De er satt opp i raid-1, så du har kun 120GB tilsammen. Er en bug begrensning i btrfs som viser at det er mer ledig plass enn det egentlig er.

https://lime-technology.com/forum/index.php?topic=45452.0

 

Her regner du ut plass du har

http://carfax.org.uk/btrfs-usage/

Endret 19. april 2016 av Bjonness406

[janfredrik]

 

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert

De er satt opp i raid-1, så du har kun 120GB tilsammen. Er en bug som viser at det er mer ledig plass enn det egentlig er.

https://lime-technology.com/forum/index.php?topic=45452.0

 

Her regner du ut plass du har

http://carfax.org.uk/btrfs-usage/

 

Ahh! Så det er egentlig litt dumt å ha den 120 GB i cachen? Kan jeg knytte en VM direkte til den disken?

[Bjonness406]

 

 

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert

De er satt opp i raid-1, så du har kun 120GB tilsammen. Er en bug som viser at det er mer ledig plass enn det egentlig er.

https://lime-technology.com/forum/index.php?topic=45452.0

 

Her regner du ut plass du har

http://carfax.org.uk/btrfs-usage/

 

Ahh! Så det er egentlig litt dumt å ha den 120 GB i cachen? Kan jeg knytte en VM direkte til den disken?

 

Bruk Unassigned Devices

[janfredrik]

Takk

 

Nå forsøkte jeg å fjerne Cache 2 (Kingston) fra poolen, og da jeg startet opp arrayet igjen stod Samsungen som unformatted. Forsøkte både med 1 og 2 slots på cache, men begge uten Kingston-disken. Hvordan får jeg kun ha Samsungen som cache?

[Bjonness406]

Takk

 

Nå forsøkte jeg å fjerne Cache 2 (Kingston) fra poolen, og da jeg startet opp arrayet igjen stod Samsungen som unformatted. Forsøkte både med 1 og 2 slots på cache, men begge uten Kingston-disken. Hvordan får jeg kun ha Samsungen som cache?

Alternativ 1: https://lime-technology.com/forum/index.php?topic=39774.0 

 

 

Alternativ 2:

 

Removing a Device from a Cache Pool

• Stop the array if it is started (go to the Main tab, click the checkbox and button to stop the array).
• Unassign the device you wish to remove from the slot it's assigned to in the cache pool.
• Physically unplug the device from the system (detach SATA and power).
• Start the array.
• A balance operation will be automatically executed; when this operation completes, an entry will be printed to the log stating disk deleted missing
• You can once again stop the array, physically reattach the previously removed device, and assign it for another purpose, such as to the array.

https://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Removing_a_Device_from_a_Cache_Pool

 

 

Alternativ 3: Hvis ikke så kan du ta et screenshot av hvor harddiskene, og så ta en new config. NB: PASS PÅ AT DU SETTER PARITY PÅ RIKITG STED, hvis du ikke gjør det så vil du miste data. Så setter du bare opp harddiskene i riktig rekkefølge og kun med en cache. 

Hvis ingen av de fungerer så vet jeg ikke, da må du nok spørre på unraid forumet

Endret 19. april 2016 av Bjonness406

[tjo099]

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert 

 

De 310 GB er ikke for 500GB'en, men hele Cache-poolen sett under ett. Du har totalt kapasitet av 620 GB, men kun 310 er tilgjengelig pga speiling av data.

Det er ikke riktig at det er Raid-1 i vanlig forstand. BTRFS filsystemet er satt opp slik at man får 50% av total kapasitet uavhengig av diskstørrelse. For min del har jeg 420 GB cache kapasitet, mens bare 210 er tilgjengelig for bruk. Dette sikrer redundans: Tidligere hadde jeg kun 2x120GB SamsungSSD'er, men jeg fikk kun 120GB, selv om jeg hadde 240 GB kapasitet.

 

Thomas

 

Endret 24. april 2016 av tjo099

[Svar]

Så BTFS Raid1 er som vanlig raid1, bare at man må ikke ha like disker mao.

[Bjonness406]

 

Noen som vet hvorfor det bare står 310 GB i size på min 500 GB SSD?

 

 

Og hvorfor Cache 2 ikke har noen definert størrelse - den er formatert

 

De 310 GB er ikke for 500GB'en, men hele Cache-poolen sett under ett. Du har totalt kapasitet av 620 GB, men kun 310 er tilgjengelig pga speiling av data.

Det er ikke riktig at det er Raid-1 i vanlig forstand. BTRFS filsystemet er satt opp slik at man får 50% av total kapasitet uavhengig av diskstørrelse. For min del har jeg 420 GB cache kapasitet, mens bare 210 er tilgjengelig for bruk. Dette sikrer redundans: Tidligere hadde jeg kun 2x120GB SamsungSSD'er, men jeg fikk kun 120GB, selv om jeg hadde 240 GB kapasitet.

 

Thomas

Det stemmer ikke helt, han får maks 120GB. Alt innholdet skal speile seg, hvordan kan du legge 310GB data inn på en 120GB ssd?

 

http://carfax.org.uk/btrfs-usage/

 

https://lime-technology.com/forum/index.php?topic=45452.0

 

Janfredrik: Hvis du vill bruke begge ssd'ene i cache, så kan du det. Du burde da skifte til raid 0, og mister da speiling av data. Så hvis en av ssd'ene ryker, så mister du det som er på begge.

Endret 24. april 2016 av Bjonness406

[siDDis]

Nærmeste jeg finner om at du skal ha ECC på FreeNAS. Er vel ikke nødvendig for ZFS, men det er helt klart anbefalt av FreeNAS folket

 

ECC RAM or Not?

This is probably the most contested issue surrounding ZFS (the filesystem that FreeNAS uses to store your data) today. I’ve run ZFS with ECC RAM and I’ve run it without. I’ve been involved in the FreeNAS community for many years and have seen people argue that ECC is required and others argue that it is a pointless waste of money. ZFS does something no other filesystem you’ll have available to you does: it checksums your data, and it checksums the metadata used by ZFS, and it checksums the checksums. If your data is corrupted in memory before it is written, ZFS will happily write (and checksum) the corrupted data. Additionally, ZFS has no pre-mount consistency checker or tool that can repair filesystem damage. This is very nice when dealing with large storage arrays as a 64TB pool can be mounted in seconds, even after a bad shutdown. However if a non-ECC memory module goes haywire, it can cause irreparable damage to your ZFS pool that can cause complete loss of the storage. For this reason, I highly recommend the use of ECC RAM with “mission-critical” ZFS. Systems with ECC RAM will correct single bit errors on the fly, and will halt the system before they can do any damage to the array if multiple bit errors are detected. If it’s imperative that your ZFS based system must always be available, ECC RAM is a requirement. If it’s only some level of annoying (slightly, moderately…) that you need to restore your ZFS system from backups, non-ECC RAM will fit the bill.

 http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-i-purpose-and-best-practices/

 

Tullete svar, lagd for å lure folk! Viktig å sjekke kjeldane dykkas før dykk drar konklusjonar.

 

Svar får ein av dei som lagde ZFS

http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271

anbefaler også denne:

http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

[Bjonness406]

 

Nærmeste jeg finner om at du skal ha ECC på FreeNAS. Er vel ikke nødvendig for ZFS, men det er helt klart anbefalt av FreeNAS folket

 

ECC RAM or Not?

This is probably the most contested issue surrounding ZFS (the filesystem that FreeNAS uses to store your data) today. I’ve run ZFS with ECC RAM and I’ve run it without. I’ve been involved in the FreeNAS community for many years and have seen people argue that ECC is required and others argue that it is a pointless waste of money. ZFS does something no other filesystem you’ll have available to you does: it checksums your data, and it checksums the metadata used by ZFS, and it checksums the checksums. If your data is corrupted in memory before it is written, ZFS will happily write (and checksum) the corrupted data. Additionally, ZFS has no pre-mount consistency checker or tool that can repair filesystem damage. This is very nice when dealing with large storage arrays as a 64TB pool can be mounted in seconds, even after a bad shutdown. However if a non-ECC memory module goes haywire, it can cause irreparable damage to your ZFS pool that can cause complete loss of the storage. For this reason, I highly recommend the use of ECC RAM with “mission-critical” ZFS. Systems with ECC RAM will correct single bit errors on the fly, and will halt the system before they can do any damage to the array if multiple bit errors are detected. If it’s imperative that your ZFS based system must always be available, ECC RAM is a requirement. If it’s only some level of annoying (slightly, moderately…) that you need to restore your ZFS system from backups, non-ECC RAM will fit the bill.

 http://www.freenas.org/blog/a-complete-guide-to-freenas-hardware-design-part-i-purpose-and-best-practices/

 

Tullete svar, lagd for å lure folk! Viktig å sjekke kjeldane dykkas før dykk drar konklusjonar.

 

Svar får ein av dei som lagde ZFS

http://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271

anbefaler også denne:

http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

 

Så FreeNAS sin hjemmeside er ikke god nok kilde for å si at det anbefales ECC memory når du bruker ZFS på freenas? Okei...

Jeg har aldri sagt at du må ha ECC på ZFS, men derimot at det er anbefalt hvis du kjører freenas og ZFS fra utviklerne av freenas. 

 

Jeg sa jo selv også at det var det nærmeste jeg fant til at ZFS trengte ECC, noe det ikke gjør, men som er anbefalt av freenas utviklerne når du kjører freenas og zfs

[siDDis]

FreeNAS utviklerar != kernel utviklerar. Det er like mykje anbefalt å køyre NTFS med ECC minne som det er med ZFS med ECC minne.

[Gjest Slettet-jDflNq]

FreeNAS har stort fokus på datasikkerhet og retter seg mot bedrifter. Selvfølgelig vil de anbefale ECC RAM når det bare er litt dyrere enn vanlig RAM og kan redde en bedrift fra å miste et viktig dokument.

[siDDis]

Ja og nei. ECC er kjempebra og sterkt anbefalt. Men mange skriver at utan ECC så kan du øydeleggja data ved vanlig bruk/scrub, det er feil! Har du først fått skrevet dokumentet til disk så er du trygg.

[strike_]

@Bjonness406 Du har en faktafeil i første post, eller ikke en fakta feil direkte, men det mangler litt info vil jeg si. Du skriver at:

 

Ikke like god hastighet når du har turbo write av. Du kan skru på turbo write for å få god hastighet, men da spinner alle harddiskene samtidig (slik som ved vanlig raid). Du kan forvente i området 40-70Mbit uten turbo write på.

 

Det finnes en alternativ måte å få bedre hastigheter på..
Unraid cacher det du skriver til arrayet til ram først, derfor får man ofte litt høyere hastighet i starten av en overføring, før det dabber litt av. Man kan konfiguere slik at unraid cacher mer til ram og dermed få høyere hastighet over tid. Så har du mer en nok ram så er dette i mine øyne et bedre alternativ enn a skrive til en cache disk, da du får filene over på arrayet med en gang isteden for å vente på at moveren skal kicke inn.

Ved bruk av vm.dirty_background_ratio og vm.dirty_ratio kommandoene kan man velge hvor mye unraid skal cache til ram før den skriver til arrayet.
 

 

vm.dirty_background_ratio is the percentage of system memory that can be filled with “dirty” pages — memory pages that still need to be written to disk — before the pdflush/flush/kdmflush background processes kick in to write it to disk. My example is 10%, so if my virtual server has 32 GB of memory that’s 3.2 GB of data that can be sitting in RAM before something is done.

 

vm.dirty_ratio is the absolute maximum amount of system memory that can be filled with dirty pages before everything must get committed to disk. When the system gets to this point all new I/O blocks until dirty pages have been written to disk. This is often the source of long I/O pauses, but is a safeguard against too much data being cached unsafely in memory.

Man kan kjøre kommandoene via ssh for å teste eller legge de til i go filen slik at de kjører ved oppstart.
Jeg bruker følgende i min go fil:

# Make unRAID cache more to ram
sysctl vm.dirty_background_ratio=60
sysctl vm.dirty_ratio=80

(igrunn trengs vel egentlig bare vm.dirty_ratio= kommandoen)

Jeg bruker da ikke cache disk til å lagre data som skal til arrayet, men cacher heller til ram slik at det blir skrevet til arrayet med en gang. Du får da gigabit hastigheter på mindre til store overføringer avhengig av hvor mye du cacher til ram. Og du slipper å ha på turbo wtite og spinne opp alle diskene. Cache disken min blir utelukkende brukt bare til vm'er og apps.

 

Har du derimot veldig store overføringer er turbo write bedre hvis man har lite ram.

Tenkte det var greit å opplyse om for de som ikke vet.

https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

 

Edit: Glemte å si at hvis man velger å skrive en høy % til ram så bør serveren være tilkoblet en UPS, slik at hvis strømmen går under en overføring så rekker man å få skrevet ut til arrayet og at det ikke ligger masse data i ram og serveren plutselig er uten strøm...

Endret 10. mai 2016 av strike_84

[Bjonness406]

- Snip - 

Takk for den! Lagt til link i førstepost til innlegget ditt  

+1