Nedostupné disky po nějaké době běhu TO

Zdravím.
Začalo se mi stávat že po nějaké době běhu TO s NAS rozšířením se nedostanu na HDD nebo je jeden nedostupný a druhý read-only. Po restartu TO je vše zas v pořádku, data poškozená nejsou.
Oba disky jsou přibližně rok staré, jinde bez problémů fungují.
Mám osazen jiný řadič ale se stejným chipem jako původní. Výměna byla provedena z důvodu snižování rychlosti sítových disků až za hranici použitelnosti (viz. https://forum.test.turris.cz/t/samba-sekani-hd-videa/7520) ( ne nemohl za to řadič )
Rovnež je dovnitř TO přidán ventilátor .
Zátěž se zdá že nemá vliv na dobu selhání.
Níže přikládám syslog https://drive.google.com/file/d/1T9XO8mD7yNQd9DhJ2rrNLTztgxTRPKj1/view?usp=sharing

Předem děkuji

Mas na nasu taky btrfs? Moje osobni zkusenost s btrfs na root partition turrisu, na nas disku, i na raspbianu je ta, ze cas od casu proste kernel neco pokazi a filesystem znici. Restart zarizeni v lepsich pripadech zaridi, ze probehne btrfs check --repair a fs je zase ok. V horsim pripade (napr. dneska na root partition meho turrisu) se s tim neda delat nic nez flashnout fs z image… Ovsem pokud to mas jako nas disk, tak bude asi jednodussi cistej format a obnovit ze zalohy (mas-li nejakou :slight_smile: ).

Je tam brtfs, dělané přes úložiště v omnii ( nevzpomenu si teď jak se to přesně jmenuje ).
Druhý disk je ext4 ale ten se stane nedostupný rovněž.
Reboot trva jen dobu než naběhne systém, netrval by ten brtfs check delší dobu?
Data po resetu jsou zcela v pořádku, z těch které jsem ověřoval. Nemám tam nic kritického ale mělo to sloužit i pro zálohy.
Pokud je to rozkopaným FS tak mám obrovskou radost protože 2TB dát není kam dát ( ze bych si zas koupil další disk?). Navíc brtfs je pod oknama nemožné a všechny live CD tučňáků odmítají spolupráci.
Poslední dobou jsem z TO zklamaný čím dál víc. Děravý router a QNAP NAS byli ve stylu nastav a zapomeň, tady je to ve stylu kazdej den něco řeš.:frowning:

Podívejte se sem USB Port Down_disk se nepřipojí, strašně podobný případ a do dneška se nepřišlo, čím to bylo. Osobně si myslím, že to jsou kontakty ale ruku do ohně nedám.

Btrfs na win jde: https://github.com/maharmstone/btrfs . Jen je to zatim trochu nestabilni, ja od toho mel nejake BSOD pri odpojeni flashdisku…

Jinak btrfs check muze byt hotovy uz cca za 10 vterin…

Ja bych si osobne netroufnul mit jedinou zalohu dat v systemu, ktery je neustale online. Zalohuju vicestupnove - na lokalni PC, na NAS, do cloudu, a na externi disk, ktery jednou za ctvrt roku pripojim k PC a odzalohuju na nej. Ten exterak neni az tak kriticky, proto staci jednou za ctvrt roku - ale je to takova prijemna pojistka treba pro pripad, ze se neco podela softwarove, znici to dulezite soubory, a ty se pak odzalohuji vsemi online zpusoby zalohovani (nebo treba ransomware)

K Omnii obecne - taky jsem cekal, ze to bude trochu vic bezstarostne, ale na druhou stranu toho po te sve chci mnohem vic, nez bych chtel po obycejnem routeru. Jedine, co si myslim, ze by se opravdu nemuselo stavat, jsou ty nahodne chyby btrfs driveru, ale tam tezko rict, kolik toho vyvojiari CZNICu zmuzou… Cekam na TOS 4, kde by mely byt vsechny drivery novejsi, tak doufam, ze pak se stabilita vyrazne zlepsi (az se odladi uvodni mouchy).

Kabely, disky, řadič je všechno nové. A v mini PCIe slotu jsou “napružené” kontakty. Navíc před jakoukoli montáží čehokoli čistím všechny kontakty koukající ven isopropylalkoholem + tvrdou gumou.
Jedinně že mikrotrhlina některého pájeného spoje ale to reset je proveden vzdáleně, na TO vůbec nesáhnu. A po resetu to funguje.

@peci1 Díky za tip, ja jsem občas použil to od DiskInternals ( s ext to funguje bezvadně ).
Důležité zálohy ( pokud to tak nazvu honosně ) jsou samozřejmě v cloudu.
Ty data které tam mám mě sice budou trápit chvíli ale nejsou nijak kritická.

Já jsem takový spíš nadšenec, takže podle tutoriálu věci zvládnu, v shellu se trochu zvladnu orientovat ale víc do toho nevidím. Navíc to “úložiště” je dostupné přes TO webové rozhraní které je spíše pro neznalé uživatele, LUCI přeci jen už chce něco víc (si myslím aspoň).
Já to mám jen jako router + NAS, líbilo se mi že místo dvou krabic bude jedna, HW specifikace taky krásná ale realita už je taková kulhající bohužel :frowning: .

Tak z Vašeho logu jsem zjisti tuto závadu:

2019-03-24 15:33:20 err kernel[]: [ 3482.273690] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x280100 action 0x6 frozen
2019-03-24 15:33:20 err kernel[]: [ 3482.281333] ata2.00: irq_stat 0x08000000, interface fatal error
2019-03-24 15:33:20 err kernel[]: [ 3482.287309] ata2.00: cmd 25/00:00:28:91:5f/00:08:76:00:00/e0 tag 11 dma 1048576 in
2019-03-24 15:33:20 err kernel[]: [ 3482.287309]          res 50/00:00:27:91:5f/00:00:76:00:00/e0 Emask 0x10 (ATA bus error)

Od tohoto okamžiku máte problémy jak s diskama, tak s FS ale i s SATA řadičem a pomůže jenom restart a autooprava FS.

To je zlé, osobně jsem se s tímto problémem nesetkal, tak jsem použil strýčka google (někde doporučují aktualizovat firmware řadiče, někde zase výměna kabelů stata2@stata3 apd. - kdo ví, jestli tam není nejaký spindown, který by vypnul řadič nebo disky při nečinosti):

https://forums.unraid.net/topic/57403-what-are-emask-0x0-sact-0x0-serr-0x0-action-0x6-frozen-errors
https://nixcasopis.com/questions/3138/jsou-tyto-chyby-sata-nebezpecne
https://bugzilla.redhat.com/show_bug.cgi?id=549981

Každopádně tyto řádky jsou příčinou Vašich problémů a nemám ponětí, čím by to mohlo být a jak to spravit. Možná se tady někdo už ozve, co a jak dál.

Děkuji všem za podněty, zkusím nastudovat ten update FW řadiče.

@kymlalu

Zdravim, podarilo se vam neco zjistit, ci to opravit? mam totiz az podezrele podobny problem. dekuji

Hezký večer,
po zkoušení jiných řadičů jsem tam nakonec vrátil původní, nahrál v té době nový TOS4 ( tuším? ) a ručně přešel na SAMBA4. Od té doby mám klid. Plus jsem trošku udělal v krabici průvan a trochu vylepšil odvod tepla z CPU a řadiče.
Chtěl jsem dělat update FW řadiče ale v TO nevím jak ( asi to nějak jde ? ) a jinak nemám kde ( není redukce / slot kam bych ten řadič plácnul ).

Mrkni jeste sem SATA HDD issues
Mam de facto stejnej problem a nevyresil jsem ho. Jde jen o druhej kanal/disk na nem pripojenej po chvilce po namountovani (v RW modu) oznami IOCTL error a odporouci se. Kdyz je pripojen v read-only modu, tak to ten error nehodi. NCQ fix v mem pripade nicemu nepomohl. Oba disky v pohode, v routeru funguji oba (v pripade pripojeni pres USB redukci a externi napajeni).

EDIT: tady se daji dekodovat ty ATA error kody: Libata error messages - ata Wiki

Podobne, bezim v NAS boxu jeden 3.5 wd black a jeden 2.5 sata ssd.

Pri niektorych bootoch sa jednoducho jeden z nich nerozbehne.

V nas boxe mam aj 8cm vetracek. Ked som ho naposledy vymienal (Arctic TC, za Noctua Redux NF-R8 1800rpm), tak som skusal aj Noctua low noise adapter. Ked som tam ten adapter pripojil, tak mi spolahlivo ani jeden z diskov nenabehol. Low noise adapter je v podstate resistor, ktory zvysuje odber, tym padom vetracku ostane menej a toci sa pomalsie.

Moja aktualna teoria je ze disky pri rozbehu maju velky power draw, a v kombinacii s vetrackem a bootujicim TO proste tahaju viac ako im zdroj vie spolahlivo dat.

Fix: noctua nf-r8 1200rpm, mensi otacky, mensi odber, issue je 1 z 10 bootov, hard reboot to fixne.

Hmm zajímavý. Já tam mám nějaký 80 Artic + rezistor( dal jsem vlastní ) a 2x HDD. A ještě nebyl problém. TO běží 24/7.
Nejvíc pomohl přechod na Sambu4 IMHO.

Power draw HDD sa moze lisit od modelu, je mozne ze mas prave taky, ktory ma nizky odber a je to v pohode.

Ten issue o ktorom rozpravame s @Maxmilian_Picmaus je to, ze disky nenabehnu pri boot-e - nezobrazia sa v Luci, System->Mount points a v kernel logu su ATA errory.