Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
- Forum Debian Users Gang
- » Instalacja i podstawowa konfiguracja
- » RAID5 resynchronizacja i bardzo długi restart
#1 2011-01-02 23:23:09
badgerman - 
Użytkownik
RAID5 resynchronizacja i bardzo długi restart
Witam. Googlałem, wymaltretowałem znajomych linuksiarzy i nie znalazłem odpowiedzi, więc mam nadzieję znaleźć ją tu.
Otóż mam sobie taki mały serwer, do FTP, Storage, Firebird, prób i innych takich.
32GB SSD PS-100 (na nim Debian Lenny)
3x1TB w RAID5 (tu jest \home i w nim też baza danych stworzona w Firebird )
Wszystko skonfigurowane przy instalacji. Problem jest taki, że jak trzeba wykonać restart, bądź rozruch systemu, trwa to niemiłosiernie długo. Operacja na jakiej stoi tak długo system to synchronizacja urządzenia md0, czyli wspomnianego RAID5. I teraz mam pytanie - czy na dwurdzeniowym procku z 4 GB DDR3 system powinien startowaćokoło 30-45 minut, czy po prostu coś nie jest tak ? Jeśli coś sknociłem, to co podać aby można było mi jakoś pomóc ?
W tej chwili zrezygnowałem z RAID5, ponieważ niestety Patriot PS100 się rozsypał i pojechał na gwarancję, w związku z tym RAID5 został rozbity, jeden z dysków pełni rolę / , jeden pozostał z funkcją /home , jeden jest unused.
Docelowo jednak chciałbym wrócić do powyższej konfiguracji.
Pytanie dodatkowe - na serwerze musi być baza danych Firebird. Jest już takowa stworzona. Jeśli przyjdzie przeinstalować Debiana na nowy dysk, to czy da się to zrobić jakoś bezboleśnie, czy niestety trzeba będzie wszystko konfigurować od nowa ? Pytanie dotyczy też przesiadki z pojedyńczego dysku na RAID5 - czy jakoś da się bez utraty danych przesiąść do starej konfiguracji ?
Offline
#2 2011-01-03 12:08:13
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Moim zdaniem coś skopałeś w konfiguracji macierzy albo pada ci jeden z dysków, lub co bardziej prawdopodobne jeden, lub więcej dysków dołączane jest do macierzy po jej starcie (bez podania konfigów/logów nie da się zgadnąć ;-) ).
Proponuję "ręczne" zrobienie macierzy przy pomocy mdadm po instalacji systemu http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch26_:_Linux_Software_RAID http://mc.ptja.pl/soft_raid.html
Co do backupu bazy http://www.firebirdsql.org/manual/gbak.html
Pytanie dotyczy też przesiadki z pojedynczego dysku na RAID5 - czy jakoś da się bez utraty danych przesiąść do starej konfiguracji ?[/quote]
Tego nie rozumiem RAID 5 to min 3 dyski/partycje?! Co tak naprawdę zrobiłeś? Wklej chociaż wynikKod:
mounti
Kod:
cat /proc/mdstat
Offline
#3 2011-01-03 12:22:37
ArnVaker - Kapelusznik
- ArnVaker
- Kapelusznik
- Skąd: Midgard
- Zarejestrowany: 2009-05-06
Re: RAID5 resynchronizacja i bardzo długi restart
[quote=badgerman]Jeśli przyjdzie przeinstalować Debiana na nowy dysk, to czy da się to zrobić jakoś bezboleśnie, czy niestety trzeba będzie wszystko konfigurować od nowa ?[/quote]
Generalnie nie trzeba nawet przeinstalowywać, wystarczy przenieść (tar, rsync, cp, ...) obecny system na nowy dysk.
[img]http://svn.debianart.org/themes/generic/spinner/spinner48px-moreblue.png[/img]
Offline
#4 2011-01-03 12:45:16
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
Tego nie rozumiem RAID 5 to min 3 dyski/partycje?! Co tak naprawdę zrobiłeś?[/quote]
znaczy tak:
docelowo serwer ma mieć 4 dyski : 1 32 GB SSD i 3 dyski talerzowe po 1 TB
ponieważ padł ten jeden SSD, to macierz rozbiłem (wtedy nie było na niej danych), jeden z dysków macierzy przeznaczyłem tymczasowo na system (bez /home ), na drugim z macierzy jest /home, a trzeci zostawiłem nieużywany. Jednak niebawem SSD wróci z wymiany, i chciałbym wrócić do zamierzonej konfiguracji, czyli SSD jako system bez /Home i 3x1TB jako RAID5 z /home . Problem taki ze serwer musi być używany przez ten czas co SSD pojechał, więc stąd pytanie czy da się jakoś przerzucić ten system z konfiguracji obecnej na docelową
Konfig macierzy wykonany był przez instalatora Debiana
Dyski są brand-new - mała jest na to szansa aby padały (każdy z innej parafii - WD, SEAGATE i SAMSUNG)
Offline
#5 2011-01-03 13:21:04
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
[quote=badgerman]Problem taki ze serwer musi być używany przez ten czas co SSD pojechał, więc stąd pytanie czy da się jakoś przerzucić ten system z konfiguracji obecnej na docelową.[/quote]
Tu odpowiedział już powyżej ArnVaker.
Ja dodam, że po skopiowaniu systemu na SSD-ka, można spróbować zrobić zdegenerowaną macierz raid 5 na dwóch dyskach przy pomocy mdadm (nie mam pojęcia jak się zachowa mdadm, czy w ogóle pozwoli zrobić raid 5 z użyciem tylko dwóch dysków - takiego czegoś jeszcze nie próbowałem). Potem przegrać na nią dane z trzeciego dysku i po jej podmontowaniu do /home i sprawdzeniu danych dołożyć trzeci dysk do macierzy.
Ostatnio edytowany przez andreq (2011-01-03 13:22:01)
Offline
#6 2011-01-03 18:27:17
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
znaczy powiem tak - mam możliwość podpięcia / skopiowania danych z tej partycji na drugi dysk i postawienie RAID z 3 czystych dysków. Mogę to zrobić, pod warunkiem ze nic nie stanie się bazie zapisanej na tym dysku
Offline
#7 2011-01-03 20:16:13
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
100% gwarancji nikt Ci nie da ;-) Zresztą jak masz dodatkowy dysk, to na nim możesz zrobić backup bazy przy pomocy gbak (link dałem powyżej), a poniżej podam Ci "przepis" jak zrobić raid5 na dwóch dyskach i później dodać trzeci.
1. Tworzysz na dwóch dyskach sda i sdb identyczne partycje typ FD (Linux raid autodetect) sda1 sdb1
2. Tworzysz macierz z dwóch dysków:
Kod:
mdadm -C -v /dev/md0 --level=5 -n 2 /dev/sda1 /dev/sdb1
3. Czekasz na synchronizację macierzy - podglądasz /proc/mdstat
4. Tworzysz na macierzy system plików:
Kod:
mkfs.ext3 /dev/md0
5. Montujesz gdzieś macierz i kopiujesz tam dane (qbak)
6. Odmontowujesz dysk źródłowy i macierz, montujesz macierz w miejsce dysku źródłowego, sprawdzasz czy baza działa
7. Jeśli tak, to odmontowujesz macierz
8. Tworzysz na dysku źródłowym partycję o identycznym rozmiarze i typie jak na początku (sdc1)
9. Dodajesz dysk do macierzy i ją powiększasz - podglądaj /proc/mdstat
Kod:
mdadm --add /dev/md0 /dev/sdc1 mdadm --grow /dev/md0 --raid-devices=3 mdadm --grow /dev/md0 --bitmap=none mdadm --grow /dev/md0 --size=max mdadm --wait /dev/md0 mdadm --grow /dev/md0 --bitmap=internal
10. Skanujesz system plików na macierzy i ją rozszerzasz (ext2/ext3)
Kod:
fsck /dev/md0 resize2fs /dev/md0
11. Podmontowujesz macierz tam gdzie ma być zamotowana sprawdzasz czy baza działa, jakby co masz kopię bazy na osobnym dysku
12. Dodajesz info o macierzy do mdadm.conf, w powyższym przykładzie zawierałby:
DEVICE /dev/sd[abc]1
ARRAY /dev/md0 devices=/dev/sda1,/dev/sdb1,/dev/sdc1[/quote]
Oczywiście dostosowujesz nazwy macierzy i partycji do własnych potrzeb.
Powyższe sprawdziłem dwa razy na virtualboxie, zero problemów, żadne dane nie utracone.
PS. Chyba zamierzasz robić backup bazy danych? Opieranie się na samym raid5 to stanowczo za mało!
Offline
#8 2011-01-03 21:57:05
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
o to właśnie chodziło. O backup bazy program ją obsługujący pyta się sam przy wyjściu, więc jakieś kopie tworzone będą na pewno. ponad to raz na jakiś czas (miesiąc, kwartał) będę to zrzucał na jakiś zewnętrzny nośnik. No chyba że masz na myśli osobny dysk na robienie backupu.
Offline
#9 2011-01-04 06:29:17
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Chodziło mi o regularne kopie na zewnętrzny nośnik.
PS. Przyjrzyj się jak te kopie robi ten program, znam przypadek gdzie właśnie pod firebirdem kopie robione były gdy były jeszcze podłączenia do bazy danych, wskutek czego kopia nie odpowiadała stanowi bazy na koniec dnia. Kolega zrezygnował z tego robiąc backup przy pomocy qbak po wcześniejszym zatrzymaniu firebirda.
Offline
#10 2011-01-04 07:42:35
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
qbak mówisz ? ja zawsze powiadam że ludzie dzielą się na tych co robią kopie i tych co muszą wpierw zapłakać. wczoraj zrobiłem kopię, ale powiem szczerze że się zastanawiam - rozmiar bazy teraz ok 3 MB, rozmiar kopii - ok 800 kb - teraz pytanie - czy jest jak mówisz, czy to po prostu zadziałało kompaktowanie bazy... ale sądzę że jeden skrypt w CRON o 4 rano co dzień (+kasowanie najstarszego - ok 7 kopii aby było ) załatwi sprawę ?
Offline
#11 2011-01-04 13:47:18
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
W linku, który wyżej podałem jest jeszcze kilka przykładów, chociażby ten: http://www.firebirdsql.org/manual/gbak-recipies.html#gbak-recipies-external-tools
Offline
#12 2011-01-12 00:26:11
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
no dobrze - wrócił do mnie dysk :)
Wymienili mi Patriota PS-100 na Torqx TRB
nie wiem czy to lepiej czy gorzej - w niedzielę będę kombinował z przeniesieniem systemu w każdym bądź razie :)
Offline
#13 2011-01-18 20:26:32
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
Witam - dojechałem do punktu 4 instrukcji andreq
Mam tylko problem teraz - jak podmontuję macierz z 2 dysków to zaczyna mi wypluwać komunikaty że napęd podłączony do portu ATA4 nie odpowiada... przez putty tego nie widać - co powinienem wkleić abyście wiedzieli gdzie może problem być ?
Offline
#14 2011-01-18 20:39:39
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Użyj sceen-a, wtedy dodatkowych zakładkach możesz wyświetlić logi, konfigi, itp. http://debian.linux.pl/threads/1298-Screen-instalacja-konfiguracja-itp.
A co masz podpięte do ATA4? Kiedyś miałem taką płytę, gdzie nieużywane porty IDE, SATA, należało wyłączyć w BIOS-ie bo inaczej waliło w konsoli "po oczach"
Offline
#15 2011-01-18 20:53:42
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
wali i to równo.
Płyta to ASRock A330ION
ma 4 saty:
SATA1: sda : Patriot TORQX TRB 32 GB (SSD)
SATA2: sdb : WD 1TB (zielona seria)
SATA3: sdc : Seagate 1TB
SATA4: sdd : Samsung 1TB (F3 zdaje się)
ale nie sadzę aby to była wina samsunga czy kabla - wymieniłem samsunga na inny dysk (drugi WD 1TB WD10EARS) i działo się to samo.
Płyta ma jeszcze 2 złącza ESATA, ale je w biosie wyłączyłem
Offline
#16 2011-01-18 21:48:30
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Rozwal na chwile tą macierz z tych dwóch dysków, utwórz na nich normalne partycje i systemy plików i skopiuj na te dyski sporą ilość danych np. katalog /usr - może zasilacz Ci nie wyrabia przy takiej ilości dysków. Objawem tego jest rozpędzanie się talerzy w dysku i wyłączanie i tak na przemian, wyczuwalne jak dotkniesz obudowy dysku.
Możesz spróbować użyć E-SATA i zobaczyć czy problem występuje, tylko musiałbyś mieć kabel e-sata <==> sata (może wina portu).
Offline
#17 2011-01-18 21:52:16
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
kabel esata do mnie jedzie
Zasilacz ? Chieftec 400W nówka sztuka - sądzę że przy ATOM'ie 3 dyski talerzowe i jeden SSD nie powinny dla niego stanowić problemu :/
Obawiam się, żę winowajcą może być płyta, która mimo że nowa potrafi spłatać figle na przykład wariować jak się podłączy do niej wszystkie 3 wentylatory i każe nimi sterować
Offline
#18 2011-01-18 22:05:22
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Niestety z Asrock-iem mam same negatywne doświadczenia. Zasilacz spokojnie pociągnie - ja miałem 360 chefteca i wyrabiał dla 4 dysków, nagrywarki i piecyka w postaci Bartona 3200+ - chyba, że teraz z jakością spadli.
Offline
#19 2011-01-19 06:56:14
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
no własnie u mnie z ASR do tej pory było zawsze mniej problemów jak z gigabyte, poza tym atom jest mało prądożerny, więc skusiłem się na takie właśnie ciekawe połączenie (płyta itx z atomem 330 , który sam żre ok 3 W w stresie, a sam jest dwuprocesorowy)
Wracając do pytania - co mam wkleić aby pomóc z identyfikacją problemu ?
To co jest wypluwane na ekran mówi cały czas o resetowaniu kanału, i braku obsługo DPO czy jakoś tak...
Offline
#20 2011-01-19 16:34:32
andreq - Członek DUG
- andreq
- Członek DUG
- Skąd: Nisko
- Zarejestrowany: 2005-01-11
Re: RAID5 resynchronizacja i bardzo długi restart
Pewnie zapisuje w /var/log/syslog.
Offline
#21 2011-01-19 17:34:03
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
znaczy jeśli potrzeba całość to zaraz coś wymyślę bo to 20 MB tekstu... najgorszy jest kawałek
Kod:
Jan 19 16:48:52 B-Serwer kernel: [50476.860853] sd 3:0:0:0: [sdd] 1953525168 512-byte hardware sectors (1000205 MB)
Jan 19 16:48:52 B-Serwer kernel: [50476.865647] sd 3:0:0:0: [sdd] Write Protect is off
Jan 19 16:48:52 B-Serwer kernel: [50476.865647] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Jan 19 16:48:52 B-Serwer kernel: [50476.865647] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: exception Emask 0x10 SAct 0x779f SErr 0x400000 action 0x6 frozen
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: irq_stat 0x08000000, interface fatal error
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4: SError: { Handshk }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/08:00:3f:17:6d/00:00:14:00:00/40 tag 0 ncq 4096 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/18:08:47:17:6d/00:00:14:00:00/40 tag 1 ncq 12288 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/30:10:5f:17:6d/00:00:14:00:00/40 tag 2 ncq 24576 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/38:18:8f:17:6d/00:00:14:00:00/40 tag 3 ncq 28672 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/18:20:c7:17:6d/00:00:14:00:00/40 tag 4 ncq 12288 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/68:38:8f:13:6d/01:00:14:00:00/40 tag 7 ncq 184320 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/38:40:57:13:6d/00:00:14:00:00/40 tag 8 ncq 28672 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/08:48:f7:14:6d/00:00:14:00:00/40 tag 9 ncq 4096 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/c8:50:77:16:6d/00:00:14:00:00/40 tag 10 ncq 102400 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/48:60:ff:14:6d/00:00:14:00:00/40 tag 12 ncq 36864 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/28:68:47:15:6d/00:00:14:00:00/40 tag 13 ncq 20480 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: cmd 61/08:70:6f:15:6d/01:00:14:00:00/40 tag 14 ncq 135168 out
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] res 40/00:14:5f:17:6d/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4.00: status: { DRDY }
Jan 19 16:48:53 B-Serwer kernel: [50478.433442] ata4: hard resetting link
Jan 19 16:48:54 B-Serwer kernel: [50478.920704] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Jan 19 16:48:54 B-Serwer kernel: [50478.925678] ata4.00: configured for UDMA/33
Jan 19 16:48:54 B-Serwer kernel: [50478.925678] ata4: EH complete
Jan 19 16:48:54 B-Serwer kernel: [50478.925678] sd 3:0:0:0: [sdd] 1953525168 512-byte hardware sectors (1000205 MB)
Jan 19 16:48:54 B-Serwer kernel: [50478.933435] sd 3:0:0:0: [sdd] Write Protect is off
Jan 19 16:48:54 B-Serwer kernel: [50478.933435] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00
Jan 19 16:48:54 B-Serwer kernel: [50479.125671] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: exception Emask 0x10 SAct 0x3e7 SErr 0x400000 action 0x6 frozen
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: irq_stat 0x08000000, interface fatal error
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4: SError: { Handshk }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/58:00:3f:3e:6e/01:00:14:00:00/40 tag 0 ncq 176128 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/90:08:6f:40:6e/00:00:14:00:00/40 tag 1 ncq 73728 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/08:10:3f:40:6e/00:00:14:00:00/40 tag 2 ncq 4096 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/00:28:3f:3c:6e/01:00:14:00:00/40 tag 5 ncq 131072 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/00:30:3f:3d:6e/01:00:14:00:00/40 tag 6 ncq 131072 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/28:38:47:40:6e/00:00:14:00:00/40 tag 7 ncq 20480 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] ata4.00: cmd 61/a8:40:97:3f:6e/00:00:14:00:00/40 tag 8 ncq 86016 out
Jan 19 16:48:54 B-Serwer kernel: [50479.674636] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.678720] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.678720] ata4.00: cmd 61/48:48:ff:40:6e/00:00:14:00:00/40 tag 9 ncq 36864 out
Jan 19 16:48:54 B-Serwer kernel: [50479.678720] res 40/00:4c:ff:40:6e/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Jan 19 16:48:54 B-Serwer kernel: [50479.678720] ata4.00: status: { DRDY }
Jan 19 16:48:54 B-Serwer kernel: [50479.678720] ata4: hard resetting link
Jan 19 16:49:00 B-Serwer kernel: [50488.655513] ata4: link is slow to respond, please be patient (ready=0)I tak w kółko... Zaczyna się to robić z chwilą podmontowania macierzy. Dopóki nie jest zamontowana w systemie jest spokój. jak się ją zamontuje ( ja montuje w /mnt/md0, ale chyba nie ma to znaczenia ? ) to zaczyna się rekontrukcja macierzy (dopiero wtedy) i właśnie konsola błędami sypie
całość dostępna tutaj
http://wklej.org/id/460055/
Jaka jest szansa na to że chipset nie daje rady z 4 dyskami ?
Dodano o 13:00 20 stycznia 2011
No cóż - kabel esata przyszedł, ale ten dysk podłączony na ESATA robi dokładnie to samo na innym porcie. Ponieważ inny dysk robi też to samo, zastanawiam się czy to ograniczenie chipsetu, czy po prostu mam uszkodzone nowe dyski... ten na ostatnim porcie to Samsung... ale wstawiałem WD i tak samo było... jakieś pomysły ? może trzeba ograniczyć zworkami dyski do 1.5 GBPS ?
skach.
Dodano o 19 20 stycznia 2011
Chyba mam przyczynę. Jednak Szajsung to Szajsung... podłączyłem w jego miejsce WD, raz splunął błędem i póki co idzie rekonstrukcja (na szajsungu osiągało w szczycie 5-7 MB, na 2x WD + 1x Seagate osiąga 39 MB) - na razie jest to macierz zdegradowana RAID5 na 2 dyskach (czyli de facto RAID0 :P ) Jak tylko się zsynchronizuje to postaram się polecieć dalej z tematem
Ostatnio edytowany przez badgerman (2011-01-20 19:04:20)
Offline
#22 2011-01-23 23:13:17
badgerman - Użytkownik
Re: RAID5 resynchronizacja i bardzo długi restart
No dobrze - powyższy patent działa świetnie. Reasumując:
1. Dyski samsunga to złooooo
2. jak zawsze profesjonalna pomoc tu jest :)
3. system działa - brak początkowych problemów z długim startem. widać po prostu coś musiało w instalatorze sie skopać,albo ten dysk szajsunga.
Na przyszłość dla chętnych:
Asrock A330ION + SSD + 3*1TB w RAID 5 to około 3 dni pracy :P
Pozdrawiam ekipę :)
Offline
Strony: 1
- Forum Debian Users Gang
- » Instalacja i podstawowa konfiguracja
- » RAID5 resynchronizacja i bardzo długi restart
Informacje debugowania
| Time (s) | Query |
|---|---|
| 0.00015 | SET CHARSET latin2 |
| 0.00004 | SET NAMES latin2 |
| 0.00112 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.142.156.58' WHERE u.id=1 |
| 0.00087 | UPDATE punbb_online SET logged=1732760478 WHERE ident='3.142.156.58' |
| 0.00054 | SELECT * FROM punbb_online WHERE logged<1732760178 |
| 0.00081 | DELETE FROM punbb_online WHERE ident='185.191.171.14' |
| 0.00070 | SELECT topic_id FROM punbb_posts WHERE id=162840 |
| 0.00008 | SELECT id FROM punbb_posts WHERE topic_id=18023 ORDER BY posted |
| 0.00224 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=18023 AND t.moved_to IS NULL |
| 0.00007 | SELECT search_for, replace_with FROM punbb_censoring |
| 0.00287 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=18023 ORDER BY p.id LIMIT 0,25 |
| 0.00077 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=18023 |
| Total query time: 0.01026 s | |