Diagnoza:
oglądamy dysk: sprzęt, konfiguracja – wszystko wydaje się
w porządku. Narzędzie do zarządzania proponuje rekonstrukcję RAID. Zgadzamy się i czekamy. Po ponad sześciu godzinach RAID jest zrekonstruowany. Zakładamy folder testowy i udostępniamy go w sieci. Teraz każdy korzysta z pamięci według własnych upodobań – aby jej użytkowanie było jak najbardziej urozmaicone. Już pierwszego dnia testu, wieczorem, RAID znów nie działa, natomiast dyski – każdy z osobna – są w porządku. Poszukiwania w Internecie pozwalają nam ustalić przyczynę: jest nią cache zapisu dysków. Sprawa okazuje się dziwna: dysk wykorzystuje go do przyjmowania poleceń zapisu – nawet jeśli akurat jest zajęty czymś innym. Jeżeli dysk obsługuje technologię NCQ, to przed wykonaniem zadań zapisu jeszcze je optymalizuje. I właśnie w tym tkwi problem: gdy dysk NAS zostanie wzbudzony (z hibernacji), po kolei włącza dyski. RAID zgłasza się dopiero, kiedy drugi dysk jest gotowy. Gdy aktywowany jest cache zapisu, dysk zgłasza się wcześniej, bo już może przyjmować polecenia. W przypadku skomplikowanego polecenia zapisu jeden dysk przez pewien czas pozostaje z tyłu za drugim. Zasadniczo działa to dobrze, bo wszystkie transmisje zostają potwierdzone
i unikamy utraty danych. Czasem jednak jakiś bit nie zostanie w porę przesłany. Po stwierdzeniu różnic pomiędzy dyskami RAID się rozpada.
Rozwiązanie:
gdy cache zapisu jest wyłączony, za kontrolę zapisu odpowiada kontroler RAID. To znacznie bezpieczniejsze rozwiązanie. W przypadku połączeń przez Ethernet lub WLAN spadek szybkości będzie niezauważalny, bo czynnikiem ograniczającym i tak jest łącze.