Bezpieczeństwo pamięci podręcznej zapisu na dyskach SATA z barierami

Czytałem ostatnio o buforowaniu zapisu, NCQ, błędach oprogramowania, barierach itp. Dotyczących napędów SATA i nie jestem pewien, jakie jest najlepsze ustawienie, które zapewniłoby bezpieczeństwo moich danych w przypadku awarii zasilania.

Z tego, co rozumiem, NCQ pozwala napędowi na zmianę kolejności zapisów w celu zoptymalizowania wydajności, przy jednoczesnym informowaniu jądra o tym, które żądania zostały fizycznie zapisane.

Pamięć podręczna zapisu powoduje, że dysk obsługuje żądanie znacznie szybciej, ponieważ nie czeka na zapisanie danych na dysku fizycznym.

Nie jestem pewien, jak mieszają się tutaj pamięć podręczna NCQ i Write ...

Systemy plików, zwłaszcza rejestrowane w dziennikach, muszą mieć pewność, kiedy określone żądanie zostało zapisane. Ponadto proces przestrzeni użytkownika używa fsync () do wymuszenia opróżnienia określonego pliku. To wywołanie fsync () nie powinno wrócić, dopóki system plików nie upewni się, że dane są zapisane na dysku.

Istnieje funkcja (FUA, Force Unit Access), którą widziałem tylko na dyskach SAS, która zmusza dysk do obejścia pamięci podręcznej i zapisu bezpośrednio na dysk. Poza tym istnieją bariery zapisu, które są mechanizmem zapewnianym przez jądro, które mogą wyzwalać opróżnianie pamięci podręcznej na dysku. Wymusza to zapisanie całej pamięci podręcznej, a nie tylko krytycznych danych, co spowalnia cały system w przypadku nadużycia, na przykład za pomocą fsync ().

Następnie są dyski z błędami oprogramowania układowego lub umyślnie kłamią na temat fizycznego zapisu danych.

Powiedziawszy to ... istnieje kilka sposobów konfiguracji napędów / systemów plików: A) NCQ i pamięć podręczna zapisu wyłączona B) Właśnie włączona obsługa NCQ C) Tylko pamięć podręczna zapisu włączona D) Zarówno NCQ, jak i pamięć podręczna zapisu

Zakładam, że bariery są włączone. BTW, jak sprawdzić, czy faktycznie są włączone?

W przypadku utraty zasilania, podczas aktywnego zapisu na dysk, domyślam się, że opcja B (NCQ, brak pamięci podręcznej) jest bezpieczna, zarówno dla dziennika systemu plików, jak i danych. Może wystąpić kara za wyniki.

Opcja D (pamięć podręczna NCQ +), jeśli używa się barier lub FUA, byłaby bezpieczna dla dziennika systemu plików i aplikacji korzystających z fsync (). Byłoby źle dla danych, które czekały w pamięci podręcznej, a system plików musi je wykryć (suma kontrolna), a przynajmniej system plików nie będzie (mam nadzieję) w niestabilnym stanie. Pod względem wydajności powinno być lepiej.

Moje pytanie brzmi jednak ... Czy coś mi brakuje? Czy jest jakaś inna zmienna, którą należy wziąć pod uwagę? Czy jest jakieś narzędzie, które mogłoby to potwierdzić i że moje dyski zachowują się tak, jak powinny?

W przypadku prostych systemów Enterprise istnieje dodatkowa warstwa w postaci adaptera pamięci (prawie zawsze karta RAID), na której istnieje jeszcze inna warstwa pamięci podręcznej. Jest dużo abstrakcji w pamięci stosu tych dni, i poszedłem do głębokiego szczegółowo w tym w serii blogu zrobiłem na Know Your I / O .

Karty RAID mogą ominąć pamięć podręczną na dysku, z których niektóre pozwalają nawet przełączać tę funkcję w systemie RAID BIOS. Jest to jeden z powodów, dla których dyski Enterprise są Enterprise, ich oprogramowanie wewnętrzne pozwala na takie rzeczy, których dyski konsumenckie ( szczególnie dyski „zielone”) nie. Ta funkcja odnosi się bezpośrednio do przypadku, o który się martwisz: awarii zasilania przy niezatwierdzonych zapisach. Pamięć podręczna karty RAID, która powinna być zasilana bateryjnie lub z pamięcią flash, zostanie zachowana do momentu przywrócenia zasilania i ponownego zapisu.

Niektóre dyski SSD dla przedsiębiorstw zawierają kondensator z wystarczającą mocą wystarczającą do zatwierdzenia wbudowanej pamięci podręcznej przed całkowitym wyłączeniem.

Jeśli pracujesz z systemem z dyskami bezpośrednio podłączonymi do płyty głównej, masz mniej zapewnień. O ile same dyski nie mają możliwości wykonania pamięci podręcznej zapisu, awaria zasilania rzeczywiście spowoduje utratę. System plików xfs zyskał reputację zawodności z powodu niemożności przetrwania tylko w tym trybie awarii; Zaprojektowano go do pracy na pełnych systemach korporacyjnych z technologiczną możliwością przeżycia pamięci.

Jednak czas się zmienił i XFS został zaprojektowany tak, aby przetrwać. Inne główne systemy plików Linux (a także NTFS w systemie Windows) miały już inżynierię, aby przetrwać w tym trybie awarii. To, jak powinno działać, polega na tym, że utracone zapisy nie pojawią się w dzienniku FS i będą wiedzieć, że nie zostały zaangażowane, więc korupcja zostanie bezpiecznie wykryta i obejść ten problem.

Wskazujesz tutaj na jeden problem: oprogramowanie układowe dysku, które leży. W takim przypadku dziennik FS przyjmie błędne założenie w stosunku do rzeczywistości, a korupcja może nie zostać wykryta przez pewien czas. Parzystość RAID i lustrzana macierz RAID mogą obejść ten problem, ponieważ należy pobrać inną zatwierdzoną kopię. Ale konfiguracje pojedynczych dysków nie będą miały tej kontroli krzyżowej, więc faktycznie będą powodować błędy.

Aby uniknąć ryzyka związanego z oprogramowaniem układowym, należy zastosować dyski klasy korporacyjnej, które uzyskują znacznie większą weryfikację (i są testowane w porównaniu z przypuszczalnymi wzorcami obciążenia), oraz projektując system pamięci masowej, aby mógł przetrwać takie nieprawdy.

Dziennik systemu plików początkowo czekał na zakończenie zapisu w dzienniku przed wydaniem zapisu do metadanych, przy założeniu, że nie było pamięci podręcznej zapisu dysku. Przy włączonym buforowaniu zapisu dysku założenie to jest zepsute i może powodować utratę danych. W ten sposób powstały bariery. Dzięki barierom dziennik może upewnić się, że zapis do dziennika zostanie zakończony przed zapisem do metadanych, nawet jeśli dysk korzysta z buforowania zapisu. W warstwie sterownika dysku bariera wymusza opróżnianie pamięci podręcznej dysku przed wysłaniem kolejnych operacji we / wy, gdy napęd zgłasza, że ​​ma pamięć podręczną zapisu i jest włączony. W przeciwnym razie nie jest to konieczne, więc bariera po prostu uniemożliwia wydanie kolejnego IO do napędu, dopóki poprzednie IO nie zostanie zakończone. NCQ oznacza po prostu, że może być konieczne poczekanie na więcej niż jedno oczekujące żądanie, zanim zostanie wydane więcej.