<p dir="ltr">Asi to tak aj spravim. Bo toto takto nejde. Ja mam s WD Red na linuxovom soft raid 1 vykonostne problemy. Vratane Qnapu. Kym bol disk sam bez raidu vsetko ficalo. Ako nahle som dal druhy a uspesne sa synchronizovalo su rychlosti ukladania na pole niekde nna urovni cca 11MB/s. S inymi diskami (WD Blue) mi to nerobi. Ale REDka pravidelne... .<br>

Mozno to nikoho na tom Qnape az tak neserie ale na pc masine ie to o hubu.<br>
J.</p>
<div class="gmail_quote">Dňa 20.11.2013 20:41 používateľ "Matus UHLAR - fantomas" <<a href="mailto:uhlar@fantomas.sk">uhlar@fantomas.sk</a>> napísal:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 20.11.13 17:36, Juraj Remenec wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Človek je tvor pohodlný. A asi som na to doplatil.<br>
Dostal som sa k serveru (obyčajné PC s Debianom a LAMP), ktorému majitelia<br>
prikúpili ďalší disk. Vraj si nemôžu dovoliť aby to vypadlo a chceli to mať<br>
tak spravené, že keď vypadne jeden disk, tak ho len vyberú a plne ho<br>
nahradí ten druhý.<br>
<br>
Áno, soft. raid poznám ale mal som dôvody ho nepoužiť. Čiastočne lenivosť a<br>
čiastočne predošlé zlé skúsenosti so soft. raidom na WD RED diskoch.<br>
</blockquote>
<br>
Ake zle? WD REd by mali byt idealne pre male firmy a 24/7 pouzitie ale je<br>
fakt ze sa objavili nejake zle serie (ci skor zle dodavky? vyklapat to<br>
bagrom asi tiez nie je najlepsi napad...)<br>
<br>
Ale na druhu stranu, RAID NIE JE zalohovanie a riesi hlavne odolnost voci<br>
vypadkom HW, nie proti chybam systemu.  Odporucam pouazivat RAID A k nemu<br>
extra backupy - disk(y), pasky alebo nejake cloudove riesenie (nie amazon<br>
glacier, ten ma ine urcenie a v pripade vypadku a nutnosti globalneho<br>
restoru je velmi drahy).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
O aktuálnosť im až tak nešlo a tak prvé čo ma napadlo bolo do crontabu<br>
hodiť raz za mesiac:<br>
dd if=/dev/sda of=/dev/sdb<br>
</blockquote>
<br>
Takto kopirujes cele disky, co je zbytocne vela dat a zbytocne velka zataz.<br>
Navyse kopirujes na blokovej urovni, nie na urovni filesystemu, cim lahko<br>
vytvoris rozbabrany filesystem.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
sdb sa po 20 minútach od poslednej aktivity vypne čím ho aj trochu šetríme<br>
a predlžujeme živostnosť.<br>
</blockquote>
<br>
Ako citam na QNAP NAS fore, podla skusenosti niektorych ludi je caste<br>
vypinanie disku rychly sposob, ako ho dostat pod kyticky.  Preslavili sa tym<br>
hlavne WD Green disky, ktore sa standardne vypinaju po 8 sekundach<br>
necinnosti).  Disky nebyvaju konstruovane aby sa kazdych par minut vypinali<br>
a zapinali.  Mozno raz za den alebo aspon par hodin, ale niekedy je lepsie<br>
vobec to neriesit.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Riešenie funkčné až do kým neprešlo prvé DD a reštart mašiny.<br>
Po boote sme si totiž všimli, že niektoré diskové partície sa pripojili z<br>
SDA disku a niektoré z SDB.<br>
Predstavte si aktuálny pripojený /www z sda a neaktuálny /var z sdb (na<br>
ktorom je mesiac stará mysql db).<br>
<br>
/etc/fstab som si všimol, že sa odkazuje na UID zariadení. Tak som to<br>
skúsil prepísať všetko na /dev/sdaX a reštartovať.<br>
</blockquote>
<br>
UUID alebo LABEL, oboje tu vyjde narovnako. <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Po reštarte sa na-mountovali už iba /dev/sdaX partície čo bol želaný efekt<br>
LENŽE, len tak zo zaujímavosti som skúsil dať:<br>
mount /dev/sdb1 /mnt  a aké bolo moje prekvapenie, keď som zistil, že obsah<br>
/mnt korešponduje s práve pripojeným /dev/sda1.<br>
Keď som skúsil dať mount /dev/sda1 /mnt, zistil som, že sa jedná v<br>
skutočnosti o disk sdb.<br>
<br>
Vždy som si myslel, že disk pripojený k SATA0 bude vždy SDA.<br>
Lenže teraz sa to tvári tak akoby sa pred bootom bral nejaký stav a po<br>
boote sa toto usporiadanie zmenilo.  To čo bolo SDA sa zmenilo na SDB ale<br>
stále to vystupuje pod hlavičkou SDA.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Snažím sa z tejto situácie "vychujiť" a zistiť, čo sa asi tak mohlo stať.<br>
Viete mi to niekto objasniť???<br>
</blockquote>
<br>
pokial viem, linux kernel od istej verzie nevie garantovat ze zariadenia sa<br>
podari inicializovat vzdy v rovnakom poradi. Sietovky sa napriklad riesia<br>
cez perzistentne pravidla, disky by sa azda mohli tiez dat...<br>
<br>
avsak to je presne dovod preco sa zariadenia identifikuju cez UUID alebo<br>
LABEL, nie cez staticke mena, ktore sa mozu menit.<br>
<br>
Riesenie ktore si na "zalohovanie" zvolil priamo vedie k takymto problemom. Odporucam ti vyskusat iny system zalohovania, nieco na suborovej urovni,<br>
pripadne schopne ukladat viac verzii suborov a skombinovat to s RAIDom.<br>
<br>
-- <br>
Matus UHLAR - fantomas, <a href="mailto:uhlar@fantomas.sk" target="_blank">uhlar@fantomas.sk</a> ; <a href="http://www.fantomas.sk/" target="_blank">http://www.fantomas.sk/</a><br>
Warning: I wish NOT to receive e-mail advertising to this address.<br>
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.<br>
Fighting for peace is like fucking for virginity...<br>
______________________________<u></u>_________________<br>
<a href="https://lists.linux.sk/mailman/listinfo/linux" target="_blank">https://lists.linux.sk/<u></u>mailman/listinfo/linux</a><br>
Meta FAQ: <a href="http://www.sklug.sk/lists/linux/metafaq.html" target="_blank">http://www.sklug.sk/lists/<u></u>linux/metafaq.html</a><br>
</blockquote></div>