Pomoc Firmware 4.1.x i restarty przy operacjach na dużej ilości danych

avis

Systems Admin...
Q's Expert
4 Grudzień 2010
364
119
43
52°17'21.9"N 21°02'45.2"E
QNAP
TVS-x71U
Ethernet
1 GbE
Większość z was mnie tu zna :p ale i tak witam :)

Jak wiadomo od niedawna możemy się cieszyć stabilna wersja QTS 4.1. Firmware jest ok gdyby nie mały fakt który jak dla mnie jest dosyć irytujący. Mianowicie odkąd używam wersji 4.1 a używam jej odkąd pojawiła się publiczna beta zauważyłem że moje skrzyneczki (pisze moje bo na początku problem dotyczył tylko jednej ale dziś zauważyłem podobne objawy na drugim moim sprzęcie) dotknął problem restartu w momencie kiedy są one zajęte operacjami na dużej ilości danych. Dokładniej np kiedy na mój mocniejszy model kopiuję dużą ilość danych (ok 1TB samych plików ISO) urządzenie w pewnym momencie doznaje zwisu i to tak totalnego że nawet nie można sie do niego dostać nawet przez SSH i jedynym wyjściem jest jego ręczne wyłączenie. Dodam że dzieje się tak i przy kopiowaniu ozywając protokołu SMB i RTRR. Innym z kolei objawem oprócz zwiechy jest po prostu restart. Na początku myślałem że problem ten dotyczy tylko jednego mojego sprzętu ale niestety dziś się dowiedziałem że mój słabszy QNAP robi to samo tyle że w tym przypadku zaliczył restart przy kasowaniu tych danych o których mówiłem powyżej poprzez File Station. stąd też zwracam się z prośbą do userów którzy posiadają ARMowe wersje QNAPów żeby dali znać czy spotkali się z takimi przypadłościami. Na koniec dodam że takich akcji nie doświadczyłem na firmware 4.0.x a kopiowałem ponad 2 razy tyle danych.

a zapomniałem dodać moje sprzęty na których mam takie akcje to:

TS-420 z 4xWD RED 2TB (Raid 5) 4.1.0 Build 0612
TS-210 z 2xSeagate Constelation 1TB (Raid 0) 4.1.0 Build 0612
 
  • Love
Reakcje: kaktus
No dobra poświęcę sie dla dobra ogółu , zaraz odpale kopiowanie 1 TB z Q na HDD i dam znać później co i jak :)no dobra - troche mniej bo 800 GB, bo nie mam miejsca na hdd w kompie :ppi razy oko 45% - bez problemu działa SSH, Debian z httrack działa dalej :)na oko 95% ... póki co ssh działa, Debian tyż :pskończyło - wsio OK
działa dalej jakby nigdy nic
jakie masz temperatury ??
 
ja ? zwykłych hdd do komputera od Seagate'a po 2 Tb - zeby bylo jasne, ja wiem co robie i jestem tego świadom.

Moim zdaniem musisz przetrzepać te dyski w programie od producenta, podejrzewałbym ze to coś raczej z nimi.
 
[10:48:35] Jason Hsu: should I go ahead and book Sept 22/23 dates and send announcements to other developers?
[10:48:35] Silas Mariusz: I hope so ;p
[10:53:20] Silas Mariusz: got qustion...
[10:53:24] Silas Mariusz: 4.1.0 firmware ... I have more and more ARM users complaining about unexpected restarts on the last f/w build
[10:53:36] Silas Mariusz: what's going on?
[10:55:17] Jason Hsu: please ask the users to contact tech support
[10:55:22] Jason Hsu: we're collecting cases
[10:55:26] Jason Hsu: still trying to find out why
[10:55:31] Jason Hsu: but it's a known issue
[10:55:32] Jason Hsu: on ARM
[10:55:46] Silas Mariusz: there was no Kernel upgrade in the last build?
[10:55:52] Silas Mariusz: cos AFAIK there was no such issues with prev. beta builds
[10:56:27] Jason Hsu: 4.1 has ARM kernel upgrade
[10:56:31] Jason Hsu: to 3.4.6

A to takie małe FYI:
[10:58:06] Silas Mariusz: holly shit!
[10:58:16] Silas Mariusz: it will not be so easy to findout what's going on
[10:58:33] Silas Mariusz: TS-ARM's kernels was always loaded with full of patches and changes done by Ken and William until he left Q
[10:59:31] Silas Mariusz: in the beginning, ... sth like a 2008, these patches was winning in faster I/O operations on ARM... Syno was far away in the performance
and Ken became 1st guy who kept the Linux idea, but in real after a year, kernel was completely different!
[11:00:03] Silas Mariusz: Like something rewroted from the basics and dedicated for ARM only...
[11:00:13] Silas Mariusz: In 2008 there was not good Toolchains for glibc 2.3.6 which was really sucks... sucks like a hell.
[11:00:33] Silas Mariusz: Anyway he dropped all limitations that was in ARMeb arch with softeabi.
[11:00:49] Silas Mariusz: So next Marvell SOCs based units on new ARMel with his Kernel was like a diamond.
[11:01:01] Silas Mariusz: QNAP anounced RAID S/W migration features...! In 2008 noone was thinking about the effiency RAID on ARM.
[11:01:41] Silas Mariusz: But... With Andy we've been investigation one issue seen only in rtorrent and no other program. Rtorrent used kernel's mmap function to alocate disk data like a RAM, and when the unit became overloaded, saved data on a disk was corrupted. CPU limit was something about 65%-70%.
[11:01:59] Silas Mariusz: Anyway... we never found the issue...
A Ty, @avis skoro masz dwa urządzenia i tylko na jednym ten problem występuje to trzeba przejrzeć natychmiast konfigurację. (Zrób obydwu urządzeni backup configów i zrewiduj.)
Z kontaktem supportu, możecie się skontaktować przez helpdesk.qnap.com lub napiszcie mi maila z danymi do logowania do serwera po SSH i hasłem administratora (co będzie konieczne). Tylko hasło inne niż domyślne 'admin', bo serwery postoją pewnie chwile otwarte.

Skontaktuje się jeszcze dziś z Artem z technicznego, zobaczymy co mi powie...

Akurat bardzo ciekawa kwestia.
Hi guys,

Please ask them to contact QNAP support. We may have found the solution. Our support team will connect to the user's NAS and provide the fix to see if it runs OK. If so, then the fix will be included in 4.1.1 for ARM.

thanks
 
No dobra co do dostępu to mogę dać ale niestety nie w tej chwili bo własnie wystąpił nowy objaw. QNAP mi sie zrestartował i własnie trwa przebudowa RAID tak więc na razie jak dla mnie to grzebanie w nim jest niewskazane. Coś chyba chłopaki przekombinowali bo szczerze mówiąc odkąd używam QNAP-a to jeszcze mi tak marnie nie chodził
 
@Silas nie poznaje cie strasznie zrobiłeś się drażliwy spokojnie nie denerwuj się każdy może mieć swoje zdanie a to że ty nie straciłeś nigdy danych to nie znaczy że ktoś inny tego nie doświadczył. Ja chciałem tylko zaznaczyć, że o ile na moim dane w razie utraty są do odtworzenia, to u niektórych nawet dłuższy brak dostępu do danych może być nie lada problemem a co dopiero ich utrata i stąd moja opinia na temat testowania wszelakich poprawek na sprzęcie klientów.

PS pisalem o narobieniu bigosu a nie o utracie danych :p
 
  • Lubię to
Reakcje: kaktus
No i tu wraca stary Silas :) jak user chce testować to niech to robi na wlasna odpowiedzialność a jak szuka pomocy to zgłasza sie do supportu :) Jak dla mnie nie musisz się spieszyc bo i tak teraz chucham i dmucham na swojego NAS-a bo kolejny raz RAID-a przebudowywuje po ostatnich akcjach z dyskiem jedzie teraz na zapasowym. To już drugi WD RED w ciągu pół roku

error page1.PNG error page2.PNG
 
Witam, jestem tu nowy...
Podepnę się pod temat ponieważ też mam problem z jednym z Qnapów, a kolega (jeśli mogę tak napisać) avis pyta czy ktoś ma podobne problemy.

Posiadam 7 Qnapów (5x TS-410U, 1x TS-412U, 1x TS-869U-RP) na wszystkie wgrany QTS 4.1.0 (2014.06.12). 3 Qnapy TS-410U robią za biblioteki backupowe - dużo danych w nocy, pozostałe udostępniają dane w sieci. Niestety z jednym Qnapem TS-410U po aktualizacji FW mam problem - codziennie w nocy zalicza restart (mniej więcej o tej samej porze), prawdopodobnie problem przy kopiowaniu dużej ilości danych - backup 3 maszyn wirtualnych. Jeżeli odłączę LAN problem nie występuje, stąd moje przypuszczenia.

Aktualizacja była ok. 29-30.07, a (co dziwne) problemy zaczęły się od 09.08...

Kopiowanie danych przez SMB, nie używam iSCSI.
 
wg mnie problem taki sam lub bardzo podobny... FW 4.1.0 b 0612 i restarty Qnapa, ale oczywiście mogę być w błędzie...
Po za tym odpowiadam na prośbę użytkownika avis cyt.: "stąd też zwracam się z prośbą do userów którzy posiadają ARMowe wersje QNAPów żeby dali znać czy spotkali się z takimi przypadłościami"
 

Użytkownicy znaleźli tą stronę używając tych słów:

  1. odzyskiwanie danych z raid
  2. dwa qnapy iscsi