NAS za domačo uporabo

Kljub temu, da je "WD Data Lifeguard Diagnostic" našel in označil bad sector (prav tako NAS) zadeva ni hotela zalaufat dokler nisem naredil remove volume in pri tem izbrisal vse podatke. Na srečo se je predhodno dala prenesti vsa vsebina na zunanji disk.
Sedaj sta dva diska v RAID 1 in pravkar prek NAS-a ponovno iščem morebitne bad sectorje.

@MajorM, ko sem istočasno naročil NAS in en disk sem si povedal, da če bo zadeva laufala OK potem ob priložnosti naročim še en disk. Ja no ta "priložnost" se je vlekla in vlekla.

Eno hitro vprašanje v zvezi z ZFS: 1gb rama na terabajt je mišljen na končno velikost "pogona" ki ga dobiš vn al na skupno velikost diskov? Sprašujem, ker me zanima če bi blo 8gb dovolj za 3x4 tera (alpa vsaj 3x3).

Dodaj tistih par GB, itak je 8 GB palčka drobiž v primerjavi s tremi 4 TB diski. Sicer pa, imaš ECC? Načeloma se uporaba ZFS-ja brez ECC-ja močno odsvetuje.

kogledom je 16. jan 2016 ob 14:13 izjavil:

PrimozR je 16. jan 2016 ob 13:55 izjavil:

Dodaj tistih par GB, itak je 8 GB palčka drobiž v primerjavi s tremi 4 TB diski. Sicer pa, imaš ECC? Načeloma se uporaba ZFS-ja brez ECC-ja močno odsvetuje.

Zakaj pa močno odsvetuje brez ECC-ja? To ni logično. Še vedno je bolj napreden FS kot večina ostalih, tudi brez ECC-RAM-a. Je pa res da se z ECC-jem poveča varnost podatkov, tako kot na drugih FS-jih.

Heh, kakšne šale pa ti stresaš. Priporočam: https://forums.freenas.org/index.php?th...

Hm... trik je v tem da 4GB DDR2 single dimme skoraj ne dobim da niso ECC Reg. kar pa plošča ne prebavi (sem malo googlal ni nobenemu ni uspelo). V najslabšem primeru bom fural 2x4TB RAID1.

kogledom je 16. jan 2016 ob 18:16 izjavil:

Tudi ECC ne popravi in tudi ne zazna vseh napak!

Slabo si prebral. Sem samo preletel, pa vseeno prebral tole:

ECC RAM can only detect and correct single bit errors. When you have multi-bit errors(if my experience is any indication) the system can detect(but not correct) those errors and immediately halts the system with a warning message on the screen with the bad memory location.

EDIT: če tole niso dovolj dobri razlogi, suit yourself:

Example 2: Server with ZFS and non-ECC RAM. Now you have more ways to lose your data:

1. If the drive completely dies(obviously).
2. Based on prior users that have had non-ECC RAM fail you'll reboot to find your pool unmountable. This means your data is gone. There is no data recovery tools out there for ZFS. NONE. It's ALL gone for good.
3. What about the fact that you used those non-server grade parts? Guess what, they can also trash your pool and make it unmountable. The outcome is exactly the same as #2. You just lost all of your data because the pool won't mount.

Poganjat ZFS brez ECC rama je neumnost! Brez ECC njegovo glavno orožje (konzistentnost podatkov) postane njegova najšibkejša točka. Brez ECC se lahko prikrade napaka, ki počasi in vztrajno brez kakršnega koli opozorila v ozadju korupta podatke. Ko ugotoviš, da je najbrž nekaj narobe, je že prepozno, da bi se dalo karkoli rešiti.

Hja, verjetno so želeli več hitrosti, največja napaka je, da niso imeli backupov serverja.

darkolord je 17. jan 2016 ob 15:36 izjavil:

V bistvu je vse fail:
- niso imeli backupa
- RAID5?!
- RAID5 z SSDji?!
- striping z RAID5?!

Grozno.

Linus!
For entertainment purposes only...

V bistvu so poskušali narediti "backup", ko je stvar bila že napol crknjena. Pri RAID5 to pač ne gre. Ko pride do naslednje napake pri branju, se cela stvar zaustavi.

Ravno to je največji problem RAID5. Če en disk zaradi kakršnega koli razloga pade iz arraya in pri branju kateregakoli od preostalih diskov pride do kakršnekoli napake, zadeva BO crknila.

darkolord je 21. jan 2016 ob 09:40 izjavil:

V bistvu so poskušali narediti "backup", ko je stvar bila že napol crknjena. Pri RAID5 to pač ne gre. Ko pride do naslednje napake pri branju, se cela stvar zaustavi.

Ravno to je največji problem RAID5. Če en disk zaradi kakršnega koli razloga pade iz arraya in pri branju kateregakoli od preostalih diskov pride do kakršnekoli napake, zadeva BO crknila.

Za katero definicijo crkotja ? Da ne boš dobil več nazaj vseh podatkov ? Ali sploh nobenega ?

AFAIK bluziš. RAID5 komot lahko assemblaš nazaj s tem, kar je ostalo in če nisi nič vpisoval, bi moral dobiti vse nazaj.

Te spooky štorije o RAID-ih so samo nabijanje, s katerimi naj bi navdušili crowd za svoje umotvore.
Marketing.
Ne rečem,d a ne držijo, so pa napihnjene in predstavljene povsem enostransko.

Brane22 je 21. jan 2016 ob 13:08 izjavil:

darkolord je 21. jan 2016 ob 09:40 izjavil:

V bistvu so poskušali narediti "backup", ko je stvar bila že napol crknjena. Pri RAID5 to pač ne gre. Ko pride do naslednje napake pri branju, se cela stvar zaustavi.

Ravno to je največji problem RAID5. Če en disk zaradi kakršnega koli razloga pade iz arraya in pri branju kateregakoli od preostalih diskov pride do kakršnekoli napake, zadeva BO crknila.

Za katero definicijo crkotja ? Da ne boš dobil več nazaj vseh podatkov ? Ali sploh nobenega ?

Nič od tega. Crkot da bo zaradi tega (pre)velik downtime.

Sestavljanje arrayev ni nekaj, kar bi si želel (ali privoščil komu) početi, ko pade produkcija oz. kritični podatki. Če se ti prav vse zvezde poravnajo in imaš vse pripravljeno (storage, na katerega boš podatke skopiral), se ne boš izognil vsaj pol dneva downtime. Bolj realno je nekaj dni.

V tistem videu eden celo omenja "the last couple of weeks". Nikjer sicer ne povedo, koliko časa je vse skupaj dejansko trajalo, je pa jasno, da precej.

Te spooky štorije o RAID-ih so samo nabijanje, s katerimi naj bi navdušili crowd za svoje umotvore.
Marketing.

Jaz širim spooky štorije, ker se mi je to dejansko zgodilo. Pri stranki je crknil array (en disk komplet crknil [pokvarjena glava in SA], dva diska sta imela bad sectorje), ki ga sam nisem uspel sestaviti, ker so bad sectorji bili nekje v začetku in sem dobival read errorje takoj, ko sem želel kar koli prebrati. Zadevo je bilo treba nesti projem, ki so za dobrih 4000 uspeli prebrati podatke in zadevo sestaviti v cca. 1 tednu. Če to ne bi uspelo, bi bila škoda res ogromna.

Brane22 je 21. jan 2016 ob 13:08 izjavil:

darkolord je 21. jan 2016 ob 09:40 izjavil:

V bistvu so poskušali narediti "backup", ko je stvar bila že napol crknjena. Pri RAID5 to pač ne gre. Ko pride do naslednje napake pri branju, se cela stvar zaustavi.

Ravno to je največji problem RAID5. Če en disk zaradi kakršnega koli razloga pade iz arraya in pri branju kateregakoli od preostalih diskov pride do kakršnekoli napake, zadeva BO crknila.

Za katero definicijo crkotja ? Da ne boš dobil več nazaj vseh podatkov ? Ali sploh nobenega ?

AFAIK bluziš. RAID5 komot lahko assemblaš nazaj s tem, kar je ostalo in če nisi nič vpisoval, bi moral dobiti vse nazaj.

Te spooky štorije o RAID-ih so samo nabijanje, s katerimi naj bi navdušili crowd za svoje umotvore.
Marketing.
Ne rečem,d a ne držijo, so pa napihnjene in predstavljene povsem enostransko.

Če ti vrže ven disk, si v nevarnem stanju. Če fašeš napako, mora kontroler vreči ven še tisti disk in kar naenkrat si iz RAID 0 (efektivni) šel na samo nič. Govorimo o URE, unrecoverable read error, torej načeloma naj ne bi bilo možno sestaviti nazaj. Morda, ampak spet, govorimo o več sreče kot pameti.

http://www.zdnet.com/article/why-raid-5...

http://www.zdnet.com/article/why-raid-6...

Aja, da smo si na jasnem, doma bi s tremi diski za NAS naredil RAID5 (oz. ga verjetno bom), ampak bodo tisti ta bolj važni podatki backupirani še na druge diske, morda še v oblak. Na RAID5 bodo torej samo tiste stvari, ki jih ni problem izgubiti (backupi sistemskih slik, travniški videoposnetki).

PrimozR je 21. jan 2016 ob 14:03 izjavil:

http://www.zdnet.com/article/why-raid-5...

http://www.zdnet.com/article/why-raid-6...

Aja, da smo si na jasnem, doma bi s tremi diski za NAS naredil RAID5 (oz. ga verjetno bom), ampak bodo tisti ta bolj važni podatki backupirani še na druge diske, morda še v oblak. Na RAID5 bodo torej samo tiste stvari, ki jih ni problem izgubiti (backupi sistemskih slik, travniški videoposnetki).

1. Uprabi Linux mdadm+RAID infrastrukturo, ne se igrat z onboard RAID jajci, sploh pa ne Winsi.

2. Če se da, ne bootat sistema z RAID-a. Zbootaj ga recimo s ključka ( katerega identično kopijo imaš dosegljivo!). Ni treba, da je na ključku celoten sistem, lahko je samo GRUB+kernel+initrd.
Toliko da sistem zna narediti v primeru potrebe diagnostiko RAID-a in filesystema na njem v priemru sile.

3. Diske montiraj tako da so hlajeni in dobro pritrjeni, brez vibracij v okolju. Ne stvari napajat za najcenejšim crap kitajskim napajalnikom za €10. Ni treba da je drag ali močan, le solidno regulacijo naj ima. Uprabi solidne SATA kable z zatiči, ki naj ne bodo bistveno predolgi.

4. Obvezno na začetku uprabi bitfield ( možen samo ob v0.9 RAID headerja). Če se ssitem ugasne z RAID v nekonsistenčnem stanju, bo rekalkulacija _bistveno_ ( v rangu tisočkrat) hitrejša.

5. cat /proc/mdstat >log_file_na_kljucek
mdadm --query /dev/moj_raid >>log_file_na_ključek

fdisk -l vseh diskov isto v log_file

zaželjeno bi bilo skopirat tudi RAID header ( je v zadnjih 128k-64k na vsakem disku array-a)

Brane22 je 21. jan 2016 ob 14:23 izjavil:

1. Uprabi Linux mdadm+RAID infrastrukturo, ne se igrat z onboard RAID jajci, sploh pa ne Winsi.

2. Če se da, ne bootat sistema z RAID-a. Zbootaj ga recimo s ključka ( katerega identično kopijo imaš dosegljivo!). Ni treba, da je na ključku celoten sistem, lahko je samo GRUB+kernel+initrd.
Toliko da sistem zna narediti v primeru potrebe diagnostiko RAID-a in filesystema na njem v priemru sile.

3. Diske montiraj tako da so hlajeni in dobro pritrjeni, brez vibracij v okolju. Ne stvari napajat za najcenejšim crap kitajskim napajalnikom za €10. Ni treba da je drag ali močan, le solidno regulacijo naj ima. Uprabi solidne SATA kable z zatiči, ki naj ne bodo bistveno predolgi.

4. Obvezno na začetku uprabi bitfield ( možen samo ob v0.9 RAID headerja). Če se ssitem ugasne z RAID v nekonsistenčnem stanju, bo rekalkulacija _bistveno_ ( v rangu tisočkrat) hitrejša.

5. cat /proc/mdstat >log_file_na_kljucek
mdadm --query /dev/moj_raid >>log_file_na_ključek

fdisk -l vseh diskov isto v log_file

zaželjeno bi bilo skopirat tudi RAID header ( je v zadnjih 128k-64k na vsakem disku array-a)

jaz bi se dodal
6) tudi zaradi geometrije razlicnih proizvajalcev, se vedno na zacetku vsakega diska naredi prazen prostor

jz grem kr na kaksen 1G
vedno se je to zelo dobro obneslo

Brane22: jaz ne promoviram/zagovarjam nobene posebne rešitve.

Dejstvo je, da ima RAID5 naslednje slabosti:
- nižji write speed
- precej nižji read speed v degraded načinu
- precej počasna resinhronizacija
- zahtevana intaktnost vseh preostalih diskov za uspešno avtomatsko resinhronizacijo

Prednosti pa:
- redundanca enega diska z uporabo samo enega dodatnega diska.

Ali je to ustrezno, se odloči vsak sam. Za filme, backupe in manj kritične podatke je to lahko prima rešitev. Za glavni storage za kritične podatke pa niti približno ne vidim scenarija, kjer bi to priporočil namesto na primer RAID10. Če je strošek dolgega downtime-a nižji od cene dveh ali treh ekstra diskov, potem pač go for it.

Mimogrede, še zanimivost (beri: good to know) glede md in RAID5 - če pri enem od disku pride do read errorja, zadeva (mislim da po defaultu) podatek sestavi iz ostalih diskov in ga poskuša zapisati nazaj. Če je to uspešno, se dela da je še vedno vse OK (array optimal). Če tega ne veš oz. če ne spremljaš sistemskega loga in tam loviš read errorje, si lahko zaradi tega precej v riti.

darkolord je 21. jan 2016 ob 15:00 izjavil:

Dejstvo je, da ima RAID5 naslednje slabosti:

OK, poglejmo si jih na realnem primeru:

RAID-5 treh poceni 2TB diskov HD203UI. En od the je padel ven iz RAID-a.

- nižji write speed

Vpis 1G bloka v filesystem: 88MiB/s. Ni slabo glede na to, da se stvar vpisuje v FS.

- precej nižji read speed v degraded načinu

Branje 1G bloka z RAID-a brez FS: 150MB/s

- precej počasna resinhronizacija

Ta je odvisna od podatkov, ki jih je treba resinhronizirati. Če imaš vklopljen bitfield, bo stvar zaznala bloke, kjer bi ta lahko bila potreban in osveži le te. kar v praksi pomeni lahko resinhronizacijo ki traja recimo par minut.

Odvisno za kaj ga rabiš. 215J je v redu za nezahtevna opravila, saj ima le 800 MHz dvojedrni procesor. Pred kratkim je Synology splavil 216, ki ni tako "podhranjen", a je zato dobrih 100 eur dražji. Potem je tu še 216play, ki dekodira H.265 (HEVC)...

215j dobim v ponedeljek. Sem tudi sam razmišljal o katerem drugem modelu in me je cena prepričala. Bo zamenjal 211j, ki je res že počasen. Za dekodiranje videa pa ga ne potrebujem, zato imam namenski predvajalnik.

Lp

Z enim slabim diskom v trodiskovnem RAID5 s počasnimi prastarimi 5400 rpm diski ?

Moj post je bil kot odgovor na trditev, da je RAID5 počasen ko je treba preračunavati podatke iz paritete.

Moje polje dela linear read 200+MB/s ko vse dela, kar je glede na uporabljene diske povsem kosher.

Čez vikend sem si na enem starem računalniku postavil NAS4FREE inštalacijo. Ni še v končni obliki (trenutno samo testni 250GB disk), nisem pa niti imel časa za kaj bolj pametnega. Imam narejen SMB/CIFS share, do katerega lahko dostopam z dveh računalnikov, en z Win7, drugi z Ubuntu 14 (občutno počasnejša povezava na žalost, ampak mislim da vem, kje je težava).

Hardver: Gigabyte GA-M61SME-S2, Athlon X2 4000+, 2GB DDR2 poceni Fasttrak RAID kartica (matična ima samo 2 SATA priključka) in najmanjše ohišje iz Swedata :P . Nameravam dat 2x1TB disk v RAID0 in 1x2TB disk kot backup teh dveh (mnenja, nasveti?). Bojazni, da bo zaradi procesorja in RAMa strežnik podhranjen, se za zdaj niso uresničile, je pa tudi res da nameravam na koncu imet 16x toliko shrambe, torej bom še videl kako bo s tem.

Skratka, zadeva je bila do zdaj bolj ali manj painless (manjši problemi so nastali le, ker se ne spoznam na networking in podobno). Strežnik je namenjen edino za backup naših računalnikov.
LP

PrimozR je 3. feb 2016 ob 21:55 izjavil:

Jaz bi tista 1 TB dal raje v JBOD. Ali pa kupi še en 2 TB disk pa naredi 2x RAID 1.

16x toliko? 32 TB? :D

Mislil sem 16x250GB, 32 tera bi blo res malo preveč :D
RAID1 rajši ne bi ker želim imet backup ki bo tam, tudi če se sistem sesuje, mogoče pa bi imel 2x 2TB JBOD. Če prav pomislim so itak povezave relativno počasne, jaz sem očitno v kameni dobi (801.11b), starša pa sta ravno tako na WiFiju torej RAID0 verjetno nebi prinesel nekih blaznih hitrosti.