Re: RAID5 - jak działa weryfikacja i naprawa?

Autor: doom3 <doom3mk_at_o2.pl>
Data: Mon 12 Jan 2009 - 01:13:58 MET
Message-ID: <gke20b$1u55$1@news2.ipartners.pl>

Użytkownik "Zbig T." <zbig_t@zbyszek.net> napisał w wiadomości
news:496a8281$1@news.home.net.pl...
> Witam
>
> Korzystam z "niby-RAIDu" na płycie Intela, opartego na rozwiązaniu Intel
> Matrix Storage Manager. Po zawieszeniu czy innym nieprawidłowym zamknięciu
> systemu, program wykonuje "weryfikację i naprawę" w celu wykrycia i
> skorygowania ewentualnych niespójności w macierzy. Rozumiem, że podczas
> tej operacji, program dla każdego "pasma" od nowa wylicza sumę kontrolną i
> porównuje ją z tą zastaną. Nie rozumiem jednak co dzieje się w przypadku,
> kiedy suma się nie zgadza. Jakie założenie jest wtedy przyjmowane? Takie,
> że "właściwa" zawartość stripe'a jest prawidłowa i nieuszkodzona i to
> niepasującą sumę kontrolną trzeba nadpisać? A może jest podejmowana
> decyzja uzależniona od jakichś czynników? Jeżeli tak to jakich? W tej
> chwili z dość dużą obawą patrzę na napis "Znaleziono i naprawiono 3 błędy
> weryfikacji" i nie daje mi to spokoju, bo nie do końca rozumiem zasadę
> działania tego procesu. Czy są racjonalne powody do obaw, że program
> "rzucił monetą" i te 3 rzekomo naprawione błędy faktycznie nie mają takiej
> zawartości jaką miały przed awarią i resetem? A może umknął mi jakiś
> istotny ogólny fakt z zasady działania macierzy RAID5?

- kazdorazowo jak zamykasz poprawnie system to macierz RAID5 a konkretniej
dyski sa synchronizowane (to tak w wielkim skrocie)
- jezeli system sie zawiesi to do synchronizacji nie dochodzi i dane na
poszczegolnych dyskach moga nie byc identyczne, z tego powodu system
sparawdza sumy kontrolne i porownuje z danymi na kazdym dysku, jezeli na
ktorym sie nie zgadza to poprawia i to w zasadzie tyle.

Oczywiscie powyzsze jest zalezne od wielu czynnikow np: OS, kontrolera,
konfiguracji kontrolera itp.

-- 
doom3 
Received on Mon Jan 12 01:15:22 2009

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Mon 12 Jan 2009 - 01:51:05 MET